Browse Source

Plan 9 from Bell Labs 2004-08-03

David du Colombier 19 years ago
parent
commit
b20189097d

+ 28 - 29
dist/replica/_plan9.db

@@ -211,7 +211,7 @@
 386/bin/disk/prep - 775 sys sys 1085077037 95880
 386/bin/disk/sacfs - 775 sys sys 1020319075 79882
 386/bin/dossrv - 775 sys sys 1085077037 136028
-386/bin/du - 775 sys sys 1085077037 68337
+386/bin/du - 775 sys sys 1091416192 71534
 386/bin/echo - 775 sys sys 1085077038 55323
 386/bin/ed - 775 sys sys 1085077038 91066
 386/bin/eqn - 775 sys sys 1087442511 242933
@@ -3157,13 +3157,13 @@ 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 1019922805 87205
+sys/doc/9.html - 664 sys sys 1091459042 87309
 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 1019922805 71930
+sys/doc/acid.html - 664 sys sys 1091459045 71723
 sys/doc/acid.ms - 664 sys sys 1015012437 64944
 sys/doc/acid.ps - 664 sys sys 1015012454 426359
-sys/doc/acidpaper.html - 664 sys sys 1019922806 46828
+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
@@ -3175,23 +3175,23 @@ 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 1019922806 14176
+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 1019922806 30830
+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 - 444 sys sys 1021580026 68719
+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 1019922807 41385
+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 1019922807 31977
+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 960837916 308797
+sys/doc/compiler.ps - 664 sys sys 1091459054 309735
 sys/doc/contents.ms - 664 sys sys 1019916701 4920
 sys/doc/contents.ps - 664 sys sys 1019916845 232629
 sys/doc/docfonts - 664 sys sys 1038117516 208
@@ -3226,23 +3226,23 @@ 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 1019922807 37017
+sys/doc/lexnames.html - 664 sys sys 1091459043 37261
 sys/doc/lexnames.ms - 644 sys sys 954383595 34046
 sys/doc/lexnames.ps - 664 sys sys 960837909 335546
-sys/doc/libmach.html - 664 sys sys 1020485624 26336
+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 1019922808 21194
+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 1019922808 38398
+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 1038117513 4265
-sys/doc/mkfiles.html - 664 sys sys 1019922808 17143
+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 1019922809 23530
+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
@@ -3255,27 +3255,27 @@ 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 1019922809 55298
+sys/doc/plumb.html - 664 sys sys 1091459044 55783
 sys/doc/plumb.ms - 644 sys sys 954383596 53250
 sys/doc/plumb.ps - 664 sys sys 960837910 391830
-sys/doc/port.html - 664 sys sys 1019922809 16498
+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 - 644 sys sys 961259497 203475
 sys/doc/prfile - 775 sys sys 944959668 3782
-sys/doc/prog4.html - 664 sys sys 1019932831 18563
+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 1019922810 39710
+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 1019922810 5869
+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 1020100480 230580
+sys/doc/release4.ps - 664 sys sys 1091459052 230868
 sys/doc/sam - 20000000775 sys sys 945617037 0
 sys/doc/sam/fig1.bm - 464 sys sys 944959645 42200
 sys/doc/sam/fig1.ps - 664 sys sys 944959645 86336
@@ -3295,10 +3295,10 @@ 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 1019922810 16618
+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 1019922811 73927
+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
@@ -3306,8 +3306,8 @@ 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 960837921 782310
-sys/doc/utf.html - 664 sys sys 1019922811 43855
+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
@@ -5369,7 +5369,7 @@ sys/src/9/pc/mp.h - 664 sys sys 1015014520 6575
 sys/src/9/pc/nv_dma.h - 664 sys sys 1081384508 12943
 sys/src/9/pc/pc - 664 sys sys 1079575705 1367
 sys/src/9/pc/pcauth - 664 sys sys 1073851852 657
-sys/src/9/pc/pccd - 664 sys sys 1055090302 1302
+sys/src/9/pc/pccd - 664 sys sys 1091458811 1408
 sys/src/9/pc/pccpu - 664 sys sys 1084475127 806
 sys/src/9/pc/pccpuf - 664 sys sys 1073851852 1315
 sys/src/9/pc/pcdisk - 664 sys sys 1073851851 1427
@@ -12335,4 +12335,3 @@ usr/glenda/lib/profile - 664 glenda glenda 1021580005 847
 usr/glenda/readme.acme - 664 glenda glenda 1019860628 4753
 usr/glenda/readme.rio - 664 glenda glenda 1019860628 6370
 usr/glenda/tmp - 20000000775 glenda glenda 1018802620 0
-386/bin/du - 775 sys sys 1091416192 71534

+ 27 - 27
dist/replica/plan9.db

@@ -3157,13 +3157,13 @@ 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 1019922805 87205
+sys/doc/9.html - 664 sys sys 1091459042 87309
 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 1019922805 71930
+sys/doc/acid.html - 664 sys sys 1091459045 71723
 sys/doc/acid.ms - 664 sys sys 1015012437 64944
 sys/doc/acid.ps - 664 sys sys 1015012454 426359
-sys/doc/acidpaper.html - 664 sys sys 1019922806 46828
+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
@@ -3175,23 +3175,23 @@ 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 1019922806 14176
+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 1019922806 30830
+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 - 444 sys sys 1021580026 68719
+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 1019922807 41385
+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 1019922807 31977
+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 960837916 308797
+sys/doc/compiler.ps - 664 sys sys 1091459054 309735
 sys/doc/contents.ms - 664 sys sys 1019916701 4920
 sys/doc/contents.ps - 664 sys sys 1019916845 232629
 sys/doc/docfonts - 664 sys sys 1038117516 208
@@ -3226,23 +3226,23 @@ 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 1019922807 37017
+sys/doc/lexnames.html - 664 sys sys 1091459043 37261
 sys/doc/lexnames.ms - 644 sys sys 954383595 34046
 sys/doc/lexnames.ps - 664 sys sys 960837909 335546
-sys/doc/libmach.html - 664 sys sys 1020485624 26336
+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 1019922808 21194
+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 1019922808 38398
+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 1038117513 4265
-sys/doc/mkfiles.html - 664 sys sys 1019922808 17143
+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 1019922809 23530
+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
@@ -3255,27 +3255,27 @@ 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 1019922809 55298
+sys/doc/plumb.html - 664 sys sys 1091459044 55783
 sys/doc/plumb.ms - 644 sys sys 954383596 53250
 sys/doc/plumb.ps - 664 sys sys 960837910 391830
-sys/doc/port.html - 664 sys sys 1019922809 16498
+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 - 644 sys sys 961259497 203475
 sys/doc/prfile - 775 sys sys 944959668 3782
-sys/doc/prog4.html - 664 sys sys 1019932831 18563
+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 1019922810 39710
+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 1019922810 5869
+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 1020100480 230580
+sys/doc/release4.ps - 664 sys sys 1091459052 230868
 sys/doc/sam - 20000000775 sys sys 945617037 0
 sys/doc/sam/fig1.bm - 464 sys sys 944959645 42200
 sys/doc/sam/fig1.ps - 664 sys sys 944959645 86336
@@ -3295,10 +3295,10 @@ 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 1019922810 16618
+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 1019922811 73927
+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
@@ -3306,8 +3306,8 @@ 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 960837921 782310
-sys/doc/utf.html - 664 sys sys 1019922811 43855
+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
@@ -5369,7 +5369,7 @@ sys/src/9/pc/mp.h - 664 sys sys 1015014520 6575
 sys/src/9/pc/nv_dma.h - 664 sys sys 1081384508 12943
 sys/src/9/pc/pc - 664 sys sys 1079575705 1367
 sys/src/9/pc/pcauth - 664 sys sys 1073851852 657
-sys/src/9/pc/pccd - 664 sys sys 1055090302 1302
+sys/src/9/pc/pccd - 664 sys sys 1091458811 1408
 sys/src/9/pc/pccpu - 664 sys sys 1084475127 806
 sys/src/9/pc/pccpuf - 664 sys sys 1073851852 1315
 sys/src/9/pc/pcdisk - 664 sys sys 1073851851 1427

+ 28 - 0
dist/replica/plan9.log

@@ -16399,3 +16399,31 @@
 1091332923 1 c 386/bin/usb/usbmouse - 775 sys sys 1091331846 137865
 1091379612 0 c sys/src/cmd/du.c - 664 sys sys 1091379562 3302
 1091417419 0 c 386/bin/du - 775 sys sys 1091416192 71534
+1091458827 0 c sys/src/9/pc/pccd - 664 sys sys 1091458811 1408
+1091460627 0 c sys/doc/9.html - 664 sys sys 1091459042 87309
+1091460627 1 c sys/doc/acid.html - 664 sys sys 1091459045 71723
+1091460627 2 c sys/doc/acidpaper.html - 664 sys sys 1091459045 46880
+1091460627 3 c sys/doc/ape.html - 664 sys sys 1091459042 14415
+1091460627 4 c sys/doc/asm.html - 664 sys sys 1091459045 31098
+1091460627 5 c sys/doc/auth.html - 664 sys sys 1091459079 77445
+1091460627 6 m sys/doc/auth.html - 664 sys sys 1091459079 77445
+1091460627 7 c sys/doc/comp.html - 664 sys sys 1091459046 42144
+1091460627 8 c sys/doc/compiler.html - 664 sys sys 1091459044 32960
+1091460627 9 c sys/doc/compiler.ps - 664 sys sys 1091459054 309735
+1091460627 10 c sys/doc/lexnames.html - 664 sys sys 1091459043 37261
+1091460627 11 c sys/doc/libmach.html - 664 sys sys 1091459044 26650
+1091460627 12 c sys/doc/lp.html - 664 sys sys 1091459043 21721
+1091460627 13 c sys/doc/mkfile - 664 sys sys 1091459055 4411
+1091460627 14 c sys/doc/release4.ps - 664 sys sys 1091459052 230868
+1091460627 15 c sys/doc/troff.ps - 664 sys sys 1091459051 782310
+1091460627 16 c sys/doc/mk.html - 664 sys sys 1091459046 40021
+1091460627 17 c sys/doc/mkfiles.html - 664 sys sys 1091459045 17750
+1091460627 18 c sys/doc/names.html - 664 sys sys 1091459046 23529
+1091460627 19 c sys/doc/plumb.html - 664 sys sys 1091459044 55783
+1091460627 20 c sys/doc/port.html - 664 sys sys 1091459042 18123
+1091460627 21 c sys/doc/prog4.html - 664 sys sys 1091459046 18653
+1091460627 22 c sys/doc/rc.html - 664 sys sys 1091459044 41702
+1091460627 23 c sys/doc/release4.html - 664 sys sys 1091459042 6473
+1091460627 24 c sys/doc/sleep.html - 664 sys sys 1091459043 16602
+1091460627 25 c sys/doc/spin.html - 664 sys sys 1091459042 75873
+1091460627 26 c sys/doc/utf.html - 664 sys sys 1091459044 43965

+ 16 - 17
sys/doc/9.html

@@ -167,7 +167,7 @@ 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.6030.gif"><br>
+<br><img src="network.pic.19237420.gif"><br>
 </PRE></TT></DL>
 </P>
 <DL>
@@ -1026,21 +1026,21 @@ a relative of
 <TT>make</TT>,
 reads the names of the current and target
 architectures from environment variables called
-<TT>$cputype</TT>
+<TT></TT><I>cputype</I>
 and
-<TT>$objtype</TT>.
+</TT><TT></TT><TT>objtype</TT>.
 By default the current processor is the target, but setting
-<TT>$objtype</TT>
+<TT></TT><I>objtype</I>
 to the name of another architecture
 before invoking
-<TT>mk</TT>
+</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>$objtype</TT>
+</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.
@@ -1273,13 +1273,13 @@ of the Plan 9 name space.
 For instance, the directory
 <TT>/bin</TT>
 is built as a union of
-<TT>/$cputype/bin</TT>
+<TT>/</TT><I>cputype/bin</I>
 (program binaries),
-<TT>/rc/bin</TT>
+</TT><TT>/rc/bin</TT>
 (shell scripts),
 and perhaps more directories provided by the user.
 This construction makes the shell
-<TT>$PATH</TT>
+</TT><TT></TT><TT>PATH</TT>
 variable unnecessary.
 </P>
 <P>
@@ -1312,7 +1312,7 @@ 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>&lt;I&gt;c&lt;/I&gt;,
+<TT>#</TT><I>c</I>,
 where
 <I>c</I>
 is a unique character (typically a letter) identifying the
@@ -2022,7 +2022,7 @@ and
 It also measures the time to send a byte on a pipe from one process
 to another and the throughput on a pipe between two processes.
 The results appear in Table 1.
-<br><img src="-.6031.gif"><br>
+<br><img src="-.19237421.gif"><br>
 Table 1.  Performance comparison.
 </P>
 <br>&#32;<br>
@@ -2040,9 +2040,9 @@ An example is the problem of heterogeneous instruction architectures,
 which is addressed by the compilers (different code characters, portable
 object code),
 the environment
-(<TT>$cputype</TT>
+(<TT></TT><I>cputype</I>
 and
-<TT>$objtype</TT>),
+</TT><TT></TT><TT>objtype</TT>),
 the name space
 (binding in
 <TT>/bin</TT>),
@@ -2260,8 +2260,8 @@ USENIX Summer Conf. Proc.,
 Nashville, June, 1991, pp. 257-265,
 reprinted in this volume.
 <DT>[Pike93]<DD>
-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;'',
+Rob Pike and Ken Thompson, ``Hello World or &#922;&#945;&#955;&#951;&#956;&#941;&#961;&#945; &#954;&#972;&#963;&#956;&#949; or
+&#12371;&#12435;&#12395;&#12385;&#12399; &#19990;&#30028;'',
 USENIX Winter Conf. Proc.,
 San Diego, 1993, pp. 43-50,
 reprinted in this volume.
@@ -2364,10 +2364,9 @@ Volume 2,
 AT&amp;T Bell Laboratories,
 Murray Hill, NJ,
 1995.
-
 </H4>
 </dl>
 <br>&#32;<br>
 <A href=http://www.lucent.com/copyright.html>
-Copyright</A> &#169; 2001 Lucent Technologies Inc.  All rights reserved.
+Copyright</A> &#169; 2004 Lucent Technologies Inc.  All rights reserved.
 </body></html>

+ 66 - 66
sys/doc/acid.html

@@ -110,11 +110,11 @@ language and program interact:
 /sys/lib/acid/port
 /sys/lib/acid/mips
 acid: new()
-75721: system call  _main ADD  $-0x14,R29
+75721: system call  _main ADD  <I>-0x14,R29
 75721: breakpoint   main+0x4   MOVW  R31,0x0(R29)
 acid: bpset(ls)
 acid: cont()
-75721: breakpoint   ls    ADD  $-0x16c8,R29
+75721: breakpoint   ls    ADD  </I>-0x16c8,R29
 acid: stk()
 At pc:0x0000141c:ls /sys/src/cmd/ls.c:87
 ls(s=0x0000004d,multi=0x00000000) /sys/src/cmd/ls.c:87
@@ -250,63 +250,63 @@ The supported format characters are:
 <DL><DD>
 </P>
 <DL COMPACT>
-<DT>&lt;TT&gt;o&lt;/TT&gt;<DD>
+<DT><TT>o</TT><DD>
 Print two-byte integer in octal.
-<DT>&lt;TT&gt;O&lt;/TT&gt;<DD>
+<DT><TT>O</TT><DD>
 Print four-byte integer in octal.
-<DT>&lt;TT&gt;q&lt;/TT&gt;<DD>
+<DT><TT>q</TT><DD>
 Print two-byte integer in signed octal.
-<DT>&lt;TT&gt;Q&lt;/TT&gt;<DD>
+<DT><TT>Q</TT><DD>
 Print four-byte integer in signed octal.
-<DT>&lt;TT&gt;B&lt;/TT&gt;<DD>
+<DT><TT>B</TT><DD>
 Print four-byte integer in binary.
-<DT>&lt;TT&gt;d&lt;/TT&gt;<DD>
+<DT><TT>d</TT><DD>
 Print two-byte integer in signed decimal.
-<DT>&lt;TT&gt;D&lt;/TT&gt;<DD>
+<DT><TT>D</TT><DD>
 Print four-byte integer in signed decimal.
-<DT>&lt;TT&gt;Y&lt;/TT&gt;<DD>
+<DT><TT>Y</TT><DD>
 Print eight-byte integer in signed decimal.
-<DT>&lt;TT&gt;Z&lt;/TT&gt;<DD>
+<DT><TT>Z</TT><DD>
 Print eight-byte integer in unsigned decimal.
-<DT>&lt;TT&gt;x&lt;/TT&gt;<DD>
+<DT><TT>x</TT><DD>
 Print two-byte integer in hexadecimal.
-<DT>&lt;TT&gt;X&lt;/TT&gt;<DD>
+<DT><TT>X</TT><DD>
 Print four-byte integer in hexadecimal.
-<DT>&lt;TT&gt;Y&lt;/TT&gt;<DD>
+<DT><TT>Y</TT><DD>
 Print eight-byte integer in hexadecimal.
-<DT>&lt;TT&gt;u&lt;/TT&gt;<DD>
+<DT><TT>u</TT><DD>
 Print two-byte integer in unsigned decimal.
-<DT>&lt;TT&gt;U&lt;/TT&gt;<DD>
+<DT><TT>U</TT><DD>
 Print four-byte integer in unsigned decimal.
-<DT>&lt;TT&gt;f&lt;/TT&gt;<DD>
+<DT><TT>f</TT><DD>
 Print single-precision floating point number.
-<DT>&lt;TT&gt;F&lt;/TT&gt;<DD>
+<DT><TT>F</TT><DD>
 Print double-precision floating point number.
-<DT>&lt;TT&gt;g&lt;/TT&gt;<DD>
+<DT><TT>g</TT><DD>
 Print a single precision floating point number in string format.
-<DT>&lt;TT&gt;G&lt;/TT&gt;<DD>
+<DT><TT>G</TT><DD>
 Print a double precision floating point number in string format.
-<DT>&lt;TT&gt;b&lt;/TT&gt;<DD>
+<DT><TT>b</TT><DD>
 Print byte in hexadecimal.
-<DT>&lt;TT&gt;c&lt;/TT&gt;<DD>
+<DT><TT>c</TT><DD>
 Print byte as an ASCII character.
-<DT>&lt;TT&gt;C&lt;/TT&gt;<DD>
+<DT><TT>C</TT><DD>
 Like
 <TT>c</TT>,
 with
 printable ASCII characters represented normally and
 others printed in the form <TT>\x</TT><I>nn</I>.
-<DT>&lt;TT&gt;s&lt;/TT&gt;<DD>
+<DT><TT>s</TT><DD>
 Interpret the addressed bytes as UTF characters
 and print successive characters until a zero byte is reached.
-<DT>&lt;TT&gt;r&lt;/TT&gt;<DD>
+<DT><TT>r</TT><DD>
 Print a two-byte integer as a rune.
-<DT>&lt;TT&gt;R&lt;/TT&gt;<DD>
+<DT><TT>R</TT><DD>
 Print successive two-byte integers as runes
 until a zero rune is reached.
-<DT>&lt;TT&gt;i&lt;/TT&gt;<DD>
+<DT><TT>i</TT><DD>
 Print as machine instructions.
-<DT>&lt;TT&gt;I&lt;/TT&gt;<DD>
+<DT><TT>I</TT><DD>
 As
 <TT>i</TT>
 above, but print the machine instructions in
@@ -315,7 +315,7 @@ an alternate form if possible:
 and
 <TT>mipsco</TT>
 reproduce the manufacturers' syntax.
-<DT>&lt;TT&gt;a&lt;/TT&gt;<DD>
+<DT><TT>a</TT><DD>
 Print the value in symbolic form.
 </DL>
 </dl>
@@ -467,7 +467,7 @@ examines and modifies Acid's map for a process.
 Name conflicts between keywords in the Acid language, symbols in the program,
 and previously defined functions are resolved when the interpreter starts up.
 Each name is made unique by prefixing enough
-<TT>$</TT>
+<TT></TT><I></I><TT>
 characters to the front of the name to make it unique. Acid reports
 a list of each name change at startup. The report looks like this:
 <DL><DT><DD><TT><PRE>
@@ -475,16 +475,16 @@ a list of each name change at startup. The report looks like this:
 /lib/acid/port
 /lib/acid/mips
 Symbol renames:
-	append=$append T/0xa4e40
+	append=</TT>append T/0xa4e40
 acid:
 </PRE></TT></DL>
 The symbol
 <TT>append</TT>
 is both a keyword and a text symbol in the program. The message reports
 that the text symbol is now named
-<TT>$append</TT>.
+<TT></TT><I>append</I><TT>.
 </P>
-<H4>Expressions
+</TT><H4>Expressions
 </H4>
 <P>
 Operators have the same
@@ -791,8 +791,8 @@ will generate Acid source code defining such complex types and functions; see
 A
 <I>unary-expression</I>
 may be qualified with a format specifier using the
-<TT>o</TT>
-perator. This has the same effect as passing the expression to the
+<TT>\</TT>
+operator. This has the same effect as passing the expression to the
 <TT>fmt</TT>
 builtin function.
 <DL><DT><DD><TT><PRE>
@@ -1214,7 +1214,7 @@ The source file address uses the same format as
 <br>
 acid: bpset(filepc("main:10"))
 acid: bptab()
-	0x00001020 usage  ADD	$-0xc,R29
+	0x00001020 usage  ADD	-0xc,R29
 </PRE></TT></DL>
 <br>
 
@@ -1235,8 +1235,8 @@ what kind of object will be fetched by the
 and
 <TT>@</TT>
 operators. The
-<TT>o</TT>
-perator is a short-hand form of the
+<TT>\</TT>
+operator is a short-hand form of the
 <TT>fmt</TT>
 builtin function. The
 <TT>fmt</TT>
@@ -1248,9 +1248,9 @@ unchanged.
 <br>
 acid: main=fmt(main, 'i') // as instructions
 acid: print(main\X, "\t", *main)
-0x00001020 ADD	$-64,R29
+0x00001020 ADD	<I>-64,R29
 </PRE></TT></DL>
-<br>
+</I><br>
 
 
 
@@ -1512,7 +1512,7 @@ environment.
 <DL><DT><DD><TT><PRE>
 <br>
 acid: newproc("-l .")
-56720: system call	_main	ADD	$-0x14,R29
+56720: system call	_main	ADD	-0x14,R29
 </PRE></TT></DL>
 <br>
 
@@ -1583,9 +1583,9 @@ acid: print(10, "decimal ", 10\D, "octal ", 10\o)
 acid: print({1, 2, 3})
 {0x00000001 , 0x00000002 , 0x00000003 }
 acid: print(main, main\a, "\t", @main\i)
-0x00001020 main	ADD	$-64,R29
+0x00001020 main	ADD	<I>-64,R29
 </PRE></TT></DL>
-<br>
+</I><br>
 
 
 
@@ -1607,7 +1607,7 @@ accepts a maximum of 512 arguments.
 <DL><DT><DD><TT><PRE>
 <br>
 acid: printto("/env/foo", "hello")
-acid: rc("echo -n $foo")
+acid: rc("echo -n foo")
 hello
 </PRE></TT></DL>
 <br>
@@ -1784,9 +1784,9 @@ is used to implement single stepping.
 <DL><DT><DD><TT><PRE>
 <br>
 acid: startstop(pid)
-75374: breakpoint	ls	ADD	$-0x16c8,R29
+75374: breakpoint	ls	ADD	<I>-0x16c8,R29
 </PRE></TT></DL>
-<br>
+</I><br>
 
 
 
@@ -1923,7 +1923,7 @@ function is passive; it does not itself cause the program to stop.
 <DL><DT><DD><TT><PRE>
 <br>
 acid: waitstop(pid)
-75374: breakpoint	ls	ADD	$-0x16c8,R29
+75374: breakpoint	ls	ADD	-0x16c8,R29
 </PRE></TT></DL>
 <br>
 
@@ -1939,15 +1939,15 @@ Acid is started.
 These modules are located in the directory
 <TT>/sys/lib/acid</TT>.
 These functions may be overridden, personalized, or added to by code defined in
-<TT>$home/lib/acid</TT>.
+<TT></TT><I>home/lib/acid</I><TT>.
 The implementation of these functions can be examined using the
-<TT>whatis</TT>
+</TT><TT>whatis</TT><TT>
 operator and then modified during debugging sessions.
 
 
 
 </P>
-<br>&#32;<br>
+</TT><br>&#32;<br>
 <DL>
 <DT><DT>&#32;<DD>
 <TT>Bsrc</TT>
@@ -2089,12 +2089,12 @@ operator.
 <DL><DT><DD><TT><PRE>
 <br>
 acid: asm(main)
-main     0x00001020 ADD    $-0x64,R29
+main     0x00001020 ADD    -0x64,R29
 main+0x4 0x00001024 MOVW   R31,0x0(R29)
 main+0x8 0x00001028 MOVW   R1,argc+4(FP)
-main+0xc 0x0000102c MOVW   $bin(SB),R1
+main+0xc 0x0000102c MOVW   <I>bin(SB),R1
 </PRE></TT></DL>
-<br>
+</I><br>
 
 
 
@@ -2201,12 +2201,12 @@ this command stops disassembling at function boundaries.
 <DL><DT><DD><TT><PRE>
 <br>
 acid: casm()
-main+0x10 0x00001030	MOVW	$0x1,R3
+main+0x10 0x00001030	MOVW	0x1,R3
 main+0x14 0x00001034	MOVW	R3,0x8(R29)
-main+0x18 0x00001038	MOVW	$0x1,R5
+main+0x18 0x00001038	MOVW	<I>0x1,R5
 main+0x1c 0x0000103c	JAL	Binit(SB)
 </PRE></TT></DL>
-<br>
+</I><br>
 
 
 
@@ -2260,7 +2260,7 @@ to fetch each object.
 acid: dump(main+35, 4, "X2bi")
 0x00001043: 0x0c8fa700 108 143 lwc2 r0,0x528f(R4) 
 0x0000104d: 0xa9006811   0   0 swc3 r0,0x0(R24) 
-0x00001057: 0x2724e800   4  37 ADD  $-0x51,R23,R31 
+0x00001057: 0x2724e800   4  37 ADD  -0x51,R23,R31 
 0x00001061: 0xa200688d   6   0 NOOP
 0x0000106b: 0x2710c000   7   0 BREAK
 </PRE></TT></DL>
@@ -2342,9 +2342,9 @@ acid: func()
 95197: breakpoint	ls+0x8	MOVW	R1,R8
 95197: breakpoint	ls+0xc	MOVW	R8,R1
 95197: breakpoint	ls+0x10	MOVW	R8,s+4(FP)
-95197: breakpoint	ls+0x14	MOVW	$0x2f,R5
+95197: breakpoint	ls+0x14	MOVW	<I>0x2f,R5
 95197: breakpoint	ls+0x18	JAL	utfrrune(SB)
-95197: breakpoint	utfrrune	ADD	$-0x18,R29
+95197: breakpoint	utfrrune	ADD	</I>-0x18,R29
 </PRE></TT></DL>
 <br>
 
@@ -2489,10 +2489,10 @@ simultaneously. The user can rotate between the copies using
 <br>
 acid: progargs="-l"
 acid: new()
-60: external interrupt	_main	ADD	$-0x14,R29
+60: external interrupt	_main	ADD	<I>-0x14,R29
 60: breakpoint	main+0x4	MOVW	R31,0x0(R29)
 </PRE></TT></DL>
-<br>
+</I><br>
 
 
 
@@ -2816,7 +2816,7 @@ function will trace down through function calls.
 acid: stmnt()
 62: breakpoint	main+0x18 MOVW	R5,0xc(R29)
 62: breakpoint	main+0x1c JAL	Binit(SB)
-62: breakpoint	Binit     ADD	$-0x18,R29
+62: breakpoint	Binit     ADD	-0x18,R29
 binit.c:91
  89	int
  90	Binit(Biobuf *bp, int f, int mode)
@@ -2898,18 +2898,18 @@ The variable
 <TT>progargs</TT>
 supplies arguments to the new process.
 The environment variable
-<TT>$8&#189;srv</TT>
+<TT></TT><I>8&#189;srv</I><TT>
 must be set to allow the interpreter to locate the mount channel for the
 window system.
 The window is created in the top left corner of the screen and is
 400x600 pixels in size. The
-<TT>win</TT>
+</TT><TT>win</TT><TT>
 function may be modified to alter the geometry.
 The window system will not be able to deliver notes in the new window
 since the pid of the created process is not passed when the server is
 mounted to create a new window.
 <DT><DT>&#32;<DD>
-<DL><DT><DD><TT><PRE>
+</TT><DL><DT><DD><TT><PRE>
 <br>
 acid: win()
 </PRE></TT></DL>
@@ -2917,5 +2917,5 @@ acid: win()
 </dl>
 <br>&#32;<br>
 <A href=http://www.lucent.com/copyright.html>
-Copyright</A> &#169; 2002 Lucent Technologies Inc.  All rights reserved.
+Copyright</A> &#169; 2004 Lucent Technologies Inc.  All rights reserved.
 </body></html>

+ 23 - 24
sys/doc/acidpaper.html

@@ -262,7 +262,7 @@ Global variables are created by assignment and need not be declared.
 All variables and functions in the program
 being debugged are entered in the Acid symbol table as global
 variables during Acid initialization.
-Conflicting variable names are resolved by prefixing enough `$' characters
+Conflicting variable names are resolved by prefixing enough `<I>' characters
 to make them unique.
 Syntactically, Acid variables and target program
 symbols are referenced identically.
@@ -277,7 +277,7 @@ accessed by indirect reference through the Acid
 variable that has the same name; the value of an Acid variable is the
 address of the corresponding program variable.
 </P>
-<H4>5 Control Flow
+</I><H4>5 Control Flow
 </H4>
 <P>
 The
@@ -359,8 +359,8 @@ argument to the result and returns that value.
 If the result is assigned to a variable,
 the new format code applies to
 that variable.  For convenience, Acid provides the
-<TT>o</TT>
-perator as a shorthand infix form of
+<TT>\</TT>
+operator as a shorthand infix form of
 <TT>fmt</TT>.
 For example:
 <DL><DT><DD><TT><PRE>
@@ -390,7 +390,7 @@ acid: p=main\i                     // p=addr(main), type INST
 acid: loop 1,5 do print(p\X, @p++) // disassemble 5 instr's
 0x0000222e LEA	0xffffe948(A7),A7
 0x00002232 MOVL	s+0x4(A7),A2
-0x00002236 PEA	0x2f($0)
+0x00002236 PEA	0x2f(0)
 0x0000223a MOVL	A2,-(A7)
 0x0000223c BSR	utfrrune
 acid:
@@ -429,28 +429,28 @@ main
 acid: *R1=10                        // modify R1
 acid: asm(*PC+4)                    // disassemble @ PC+4
 main+0x4 0x00006240 	MOVW	R31,0x0(R29)
-main+0x8 0x00006244 	MOVW	$setR30(SB),R30
+main+0x8 0x00006244 	MOVW	<I>setR30(SB),R30
 main+0x10 0x0000624c 	MOVW	R1,_clock(SB)
 </PRE></TT></DL>
 Here, the saved
-<TT>PC</TT>
+</I><TT>PC</TT><I>
 is stored at address
-<TT>0xc0000f60</TT>;
+</I><TT>0xc0000f60</TT><I>;
 its current content is
-<TT>0x0000623c</TT>.
+</I><TT>0x0000623c</TT><I>.
 The
-`<TT>a</TT>'
+`</I><TT>a</TT><I>'
 format code converts this value to a string specifying
 the address as an offset beyond the nearest symbol.
 After setting the value of register
-<TT>1</TT>,
+</I><TT>1</TT><I>,
 the example uses the
-<TT>asm</TT>
+</I><TT>asm</TT><I>
 command to disassemble a short section of code beginning
 at four bytes beyond the current value of the
-<TT>PC</TT>.
+</I><TT>PC</TT><I>.
 </P>
-<H4>7 Process Interface
+</I><H4>7 Process Interface
 </H4>
 <P>
 A program executing under Acid is monitored through the
@@ -535,7 +535,7 @@ main(int argc, char *argv[])
 acid: src(*PC)			// print statements nearby
  9
  10 void
-&#62;11 main(int argc, char *argv[])
+&gt;11 main(int argc, char *argv[])
  12 {
  13	int a;
 </PRE></TT></DL>
@@ -584,7 +584,7 @@ illustrate the interaction of the debugger and the interpreter.
 <DL><DT><DD><TT><PRE>
 defn bpset(addr)                          // set breakpoint
 {
-	if match(addr, bplist) &#62;= 0 then
+	if match(addr, bplist) &gt;= 0 then
 		print("bkpoint already set:", addr\a, "\n");
 	else {
 		*fmt(addr, bpfmt) = bpinst;   // plant it
@@ -623,7 +623,7 @@ defn step()				// single step
 	local lst, lpl, addr, bput;
 
 	bput = 0;			// sitting on bkpoint
-	if match(*PC, bplist) &#62;= 0 then {	
+	if match(*PC, bplist) &gt;= 0 then {	
 		bput = fmt(*PC, bpfmt);	// save current addr
 		*bput = @bput;		// replace it
 	}
@@ -728,10 +728,10 @@ defn next()
 	bound = fnbound(*PC);		// begin &amp; end of fn.
 	stmnt();			// step 1 statement
 	pc = *PC;
-	if pc &#62;= bound[0] &amp;&amp; pc &#60; bound[1] then
+	if pc &gt;= bound[0] &amp;&amp; pc &lt; bound[1] then
 		return {};
 
-	while (pc&#60;bound[0] || pc&#62;bound[1]) &amp;&amp; sp&#62;=*SP do {
+	while (pc&lt;bound[0] || pc&gt;bound[1]) &amp;&amp; sp&gt;=*SP do {
 		step();
 		pc = *PC;
 	}
@@ -1008,7 +1008,7 @@ complex data type.
 Acid borrows the C operators
 <TT>.</TT>
 and
-<TT>-></TT>
+<TT>-&gt;</TT>
 to access the decoding parameters of a member of a complex type.
 Although this representation is sufficiently general for describing
 the decoding of both C and Alef complex data types, it may
@@ -1053,12 +1053,12 @@ now
 is
 the
 time
-&#60;ctrl-d&#62;
+&lt;ctrl-d&gt;
 is
 now
 the
 time
-27680 : breakpoint	_exits+0x4	MOVW	$0x8,R1
+27680 : breakpoint	_exits+0x4	MOVW	0x8,R1
 acid: 
 </PRE></TT></DL>
 The
@@ -1362,8 +1362,7 @@ San Antonio, TX.
 Proceedings of the Third International Conference on Architectural
 Support for Programming Languages and Operating Systems,
 SIGPLAN notices Nr. 22, May 1989.
-
 <br>&#32;<br>
 <A href=http://www.lucent.com/copyright.html>
-Copyright</A> &#169; 2000 Lucent Technologies Inc.  All rights reserved.
+Copyright</A> &#169; 2004 Lucent Technologies Inc.  All rights reserved.
 </body></html>

+ 37 - 38
sys/doc/ape.html

@@ -43,7 +43,7 @@ The
 command acts as a front end to the Plan 9 C compilers and loaders.
 It runs an ANSI C preprocessor over source files, using the APE
 headers to satisfy
-<TT>#include <<I>file</I>></TT>
+<TT>#include &lt;</TT><I>file</I><TT>&gt;</TT>
 directives; then it runs a Plan 9 C compiler; finally, it may load
 with APE libraries to produce an executable program.
 The document
@@ -51,12 +51,12 @@ The document
 explains how environment variables are used by convention to
 handle compilation for differing architectures.
 The environment variable
-<TT>$objtype</TT>
+<TT></TT><I>objtype</I>
 controls which Plan 9 compiler and loader are used by
-<TT>pcc</TT>,
+</TT><TT>pcc</TT>,
 as well as the location of header and library files.
 For example, if
-<TT>$objtype</TT>
+</TT><TT></TT><TT>objtype</TT>
 is
 <TT>mips</TT>,
 then
@@ -147,17 +147,17 @@ to turn on ANSI prototype warnings;
 <TT>-S</TT>
 to leave assembly language in
 <I>file</I>.s;
-<TT>-Wp,<I>args</I></TT>
+<TT>-Wp,</TT><I>args</I><TT></TT>
 to pass
 <I>args</I>
 to the
 <TT>cpp</TT>;
-<TT>-W0,<I>args</I></TT>
+<TT>-W0,</TT><I>args</I><TT></TT>
 to pass
 <I>args</I>
 to 2c, etc.;
 and
-<TT>-Wl,<I>args</I></TT>
+<TT>-Wl,</TT><I>args</I><TT></TT>
 to pass
 <I>args</I>
 to 2l, etc.
@@ -201,10 +201,10 @@ The most important feature test macro is
 when it is defined, exactly the symbols required by POSIX are
 visible in the appropriate headers.
 Consider
-<TT><signal.h></TT>
+<TT>&lt;signal.h&gt;</TT>
 for example:
 ANSI defines some names that must be defined in
-<TT><signal.h></TT>,
+<TT>&lt;signal.h&gt;</TT>,
 but POSIX defines others, such as
 <TT>sigset_t</TT>,
 which are not allowed according to ANSI.
@@ -238,7 +238,7 @@ by the C or POSIX standard, and those required by the POSIX standard
 are protected by
 <TT>#ifdef _POSIX_SOURCE</TT>.
 For example,
-<TT><errno.h></TT>
+<TT>&lt;errno.h&gt;</TT>
 defines
 <TT>EDOM</TT>,
 <TT>ERANGE</TT>,
@@ -294,7 +294,7 @@ The functions are as described in the Plan 9 manual (see
 had to be renamed
 <TT>ptdiv</TT>.
 Include the
-<TT><libg.h></TT>
+<TT>&lt;libg.h&gt;</TT>
 header to declare the needed types and functions.
 <DT>   -<DD>
 <TT>_LIMITS_EXTENSION</TT>.
@@ -303,12 +303,12 @@ POSIX does not require that names such as
 and
 <TT>OPEN_MAX</TT>
 be defined in
-<TT><limits.h></TT>,
+<TT>&lt;limits.h&gt;</TT>,
 but many programs assume they are defined there.
 If
 <TT>_LIMITS_EXTENSION</TT>
 is defined, those names will all be defined when
-<TT><limits.h></TT>
+<TT>&lt;limits.h&gt;</TT>
 is included.
 <DT>   -<DD>
 <TT>_BSD_EXTENSION</TT>.
@@ -316,45 +316,45 @@ This extension includes not only Berkeley Unix routines,
 but also a grab bag of other miscellaneous routines often
 found in Unix implementations.
 The extension allows the inclusion of any of:
-<TT><bsd.h></TT>
+<TT>&lt;bsd.h&gt;</TT>
 for
 <TT>bcopy()</TT>,
 <TT>bcmp()</TT>,
 and similar Berkeley functions;
-<TT><netdb.h></TT>
+<TT>&lt;netdb.h&gt;</TT>
 for
 <TT>gethostbyname()</TT>,
 etc.,
 and associated structures;
-<TT><select.h></TT>
+<TT>&lt;select.h&gt;</TT>
 for the Berkeley
 <TT>select</TT>
 function and associated types and macros
 for dealing with multiple input sources;
-<TT><sys/ioctl.h></TT>
+<TT>&lt;sys/ioctl.h&gt;</TT>
 for the
 <TT>ioctl</TT>
 function (minimally implemented);
-<TT><sys/param.h></TT>
+<TT>&lt;sys/param.h&gt;</TT>
 for
 <TT>NOFILES_MAX</TT>;
-<TT><sys/pty.h></TT>
+<TT>&lt;sys/pty.h&gt;</TT>
 for pseudo-tty support via the
 <TT>ptsname(int)</TT>
 and
 <TT>ptmname(int)</TT>
 functions;
-<TT><sys/resource.h></TT>;
-<TT><sys/socket.h></TT>
+<TT>&lt;sys/resource.h&gt;</TT>;
+<TT>&lt;sys/socket.h&gt;</TT>
 for socket structures, constants, and functions;
-<TT><sys/time.h></TT>
+<TT>&lt;sys/time.h&gt;</TT>
 for definitions of the
 <TT>timeval</TT>
 and
 <TT>timezone</TT>
 structures;
 and
-<TT><sys/uio.h></TT>
+<TT>&lt;sys/uio.h&gt;</TT>
 for the
 <TT>iovec</TT>
 structure and the
@@ -365,23 +365,23 @@ functions used for scatter/gather I/O.
 Defining
 <TT>_BSD_EXTENSION</TT>
 also enables various extra definitions in
-<TT><ctype.h></TT>,
-<TT><signal.h></TT>,
-<TT><stdio.h></TT>,
-<TT><unistd.h></TT>,
-<TT><sys/stat.h></TT>,
+<TT>&lt;ctype.h&gt;</TT>,
+<TT>&lt;signal.h&gt;</TT>,
+<TT>&lt;stdio.h&gt;</TT>,
+<TT>&lt;unistd.h&gt;</TT>,
+<TT>&lt;sys/stat.h&gt;</TT>,
 and
-<TT><sys/times.h></TT>.
+<TT>&lt;sys/times.h&gt;</TT>.
 <DT>   -<DD>
 <TT>_NET_EXTENSION</TT>.
 This extension allows inclusion of
-<TT><libnet.h></TT>,
+<TT>&lt;libnet.h&gt;</TT>,
 which defines the networking functions described in the Plan 9 manual page
 <A href="/magic/man2html/2/dial"><I>dial</I>(2).
 </A><DT>   -<DD>
 <TT>_REGEXP_EXTENSION</TT>.
 This extension allows inclusion of
-<TT><regexp.h></TT>,
+<TT>&lt;regexp.h&gt;</TT>,
 which defines the regular expression matching functions described
 in the Plan 9 manual page
 <A href="/magic/man2html/2/regexp"><I>regexp</I>(2).
@@ -390,7 +390,7 @@ in the Plan 9 manual page
 This extension enables a small library of functions from the Tenth Edition Unix
 Research System (V10).
 These functions and the types needed to use them are all defined in the
-<TT><libv.h></TT>
+<TT>&lt;libv.h&gt;</TT>
 header.
 The provided functions are:
 <TT>srand</TT>,
@@ -441,7 +441,7 @@ A good strategy for porting external programs is to first try using
 if that doesn't work, try adding
 <TT>_D_BSD_EXTENSION</TT>
 and perhaps include
-<TT><bsd.h></TT>
+<TT>&lt;bsd.h&gt;</TT>
 in source files.
 Here are some solutions to problems that might remain:
 </P>
@@ -456,15 +456,15 @@ global instead.
 <TT>OPEN_MAX</TT>,
 <TT>PATH_MAX</TT>,
 etc., assumed in
-<TT><limits.h></TT>.
+<TT>&lt;limits.h&gt;</TT>.
 Rewrite to call
 <TT>sysconf</TT>
 or define
 <TT>_LIMITS_EXTENSION</TT>.
 <DT>   -<DD>
-<TT><varargs.h></TT>.
+<TT>&lt;varargs.h&gt;</TT>.
 Rewrite to use
-<TT><stdarg.h></TT>.
+<TT>&lt;stdarg.h&gt;</TT>.
 </dl>
 <P>
 The second class of problems has to do with inadequacies in the Plan 9
@@ -525,9 +525,8 @@ code that does
 should be changed to
 <TT>getenv("home")</TT>
 on Plan 9.
-
 </dl>
 <br>&#32;<br>
 <A href=http://www.lucent.com/copyright.html>
-Copyright</A> &#169; 2000 Lucent Technologies Inc.  All rights reserved.
+Copyright</A> &#169; 2004 Lucent Technologies Inc.  All rights reserved.
 </body></html>

+ 52 - 53
sys/doc/asm.html

@@ -160,7 +160,7 @@ offsets to
 <TT>SB</TT>,
 as in
 <DL><DT><DD><TT><PRE>
-	MOVL	$array(SB), TOS
+	MOVL	<I>array(SB), TOS
 </PRE></TT></DL>
 to push the address of a global array on the stack, or
 <DL><DT><DD><TT><PRE>
@@ -169,22 +169,22 @@ to push the address of a global array on the stack, or
 to push the second (4-byte) element of the array.
 Note the use of an offset; the complete list of addressing modes is given below.
 Similarly, subroutine calls must use
-<TT>SB</TT>:
+</I><TT>SB</TT><I>:
 <DL><DT><DD><TT><PRE>
 	BSR	exit(SB)
 </PRE></TT></DL>
 File-static variables have syntax
 <DL><DT><DD><TT><PRE>
-	local&#60;&#62;+4(SB)
+	local&lt;&gt;+4(SB)
 </PRE></TT></DL>
 The
-<TT><></TT>
+</I><TT>&lt;&gt;</TT><I>
 will be filled in at load time by a unique integer.
 </P>
-<P>
+</I><P>
 When a program starts, it must execute
 <DL><DT><DD><TT><PRE>
-	MOVL	$a6base(SB), A6
+	MOVL	a6base(SB), A6
 </PRE></TT></DL>
 before accessing any global data.
 (On machines such as the MIPS and SPARC that cannot load a register
@@ -239,7 +239,7 @@ to indicate the size and scaling of the data.
 </P>
 <DL>
 <DT><DT>&#32;<DD>
-<br><img src="data.10610.gif"><br>
+<br><img src="data.19116310.gif"><br>
 </dl>
 <H4>Laying down data
 </H4>
@@ -254,23 +254,23 @@ and
 lay down the value of their single argument, of the appropriate size,
 as if it were an instruction:
 <DL><DT><DD><TT><PRE>
-	LONG	$12345
+	LONG	<I>12345
 </PRE></TT></DL>
 places the long 12345 (base 10)
 in the instruction stream.
 (On most machines,
 the only such operator is
-<TT>WORD</TT>
+</I><TT>WORD</TT><I>
 and it lays down 32-bit quantities.
 The 386 has all three:
-<TT>LONG</TT>,
-<TT>WORD</TT>,
+</I><TT>LONG</TT><I>,
+</I><TT>WORD</TT><I>,
 and
-<TT>BYTE</TT>.
+</I><TT>BYTE</TT><I>.
 The 960 has only one,
-<TT>LONG</TT>.)
+</I><TT>LONG</TT><I>.)
 </P>
-<P>
+</I><P>
 Placing information in the data section is more painful.
 The pseudo-instruction
 <TT>DATA</TT>
@@ -282,57 +282,57 @@ containing the characters
 <TT>abc</TT>
 and a terminating null:
 <DL><DT><DD><TT><PRE>
-	DATA    array+0(SB)/1, $'a'
-	DATA    array+1(SB)/1, $'b'
-	DATA    array+2(SB)/1, $'c'
-	GLOBL   array(SB), $4
+	DATA    array+0(SB)/1, 'a'
+	DATA    array+1(SB)/1, <I>'b'
+	DATA    array+2(SB)/1, </I>'c'
+	GLOBL   array(SB), <I>4
 </PRE></TT></DL>
 or
 <DL><DT><DD><TT><PRE>
-	DATA    array+0(SB)/4, $"abc\z"
-	GLOBL   array(SB), $4
+	DATA    array+0(SB)/4, </I>"abc\z"
+	GLOBL   array(SB), <I>4
 </PRE></TT></DL>
 The
-<TT>/1</TT>
+</I><TT>/1</TT><I>
 defines the number of bytes to define,
-<TT>GLOBL</TT>
+</I><TT>GLOBL</TT><I>
 makes the symbol global, and the
-<TT>$4</TT>
+</I><TT></TT><I>4</I><TT>
 says how many bytes the symbol occupies.
 Uninitialized data is zeroed automatically.
 The character
-<TT>z</TT>
+</TT><TT>\z</TT><TT>
 is equivalent to the C
-<TT> .</TT>
+</TT><TT>\0.</TT><TT>
 The string in a
-<TT>DATA</TT>
+</TT><TT>DATA</TT><TT>
 statement may contain a maximum of eight bytes;
 build larger strings piecewise.
 Two pseudo-instructions,
-<TT>DYNT</TT>
+</TT><TT>DYNT</TT><TT>
 and
-<TT>INIT</TT>,
+</TT><TT>INIT</TT><TT>,
 allow the (obsolete) Alef compilers to build dynamic type information during the load
 phase.
 The
-<TT>DYNT</TT>
+</TT><TT>DYNT</TT><TT>
 pseudo-instruction has two forms:
 <DL><DT><DD><TT><PRE>
 	DYNT	, ALEF_SI_5+0(SB)
 	DYNT	ALEF_AS+0(SB), ALEF_SI_5+0(SB)
 </PRE></TT></DL>
 In the first form,
-<TT>DYNT</TT>
+</TT><TT>DYNT</TT><TT>
 defines the symbol to be a small unique integer constant, chosen by the loader,
 which is some multiple of the word size.  In the second form,
-<TT>DYNT</TT>
+</TT><TT>DYNT</TT><TT>
 defines the second symbol in the same way,
 places the address of the most recently
 defined text symbol in the array specified by the first symbol at the
 index defined by the value of the second symbol,
 and then adjusts the size of the array accordingly.
 </P>
-<P>
+</TT><P>
 The
 <TT>INIT</TT>
 pseudo-instruction takes the same parameters as a
@@ -363,20 +363,20 @@ and restore instructions, even if the function is not a leaf.
 Here is a complete procedure that returns the sum
 of its two arguments:
 <DL><DT><DD><TT><PRE>
-TEXT	sum(SB), $0
+TEXT	sum(SB), <I>0
 	MOVL	arg1+0(FP), R0
 	ADDL	arg2+4(FP), R0
 	RTS
 </PRE></TT></DL>
 An optional middle argument
 to the
-<TT>TEXT</TT>
+</I><TT>TEXT</TT><I>
 pseudo-op is a bit field of options to the loader.
 Setting the 1 bit suspends profiling the function when profiling is enabled for the rest of
 the program.
 For example,
 <DL><DT><DD><TT><PRE>
-TEXT	sum(SB), 1, $0
+TEXT	sum(SB), 1, </I>0
 	MOVL	arg1+0(FP), R0
 	ADDL	arg2+4(FP), R0
 	RTS
@@ -433,29 +433,29 @@ does not distinguish between the various forms of
 instruction: move quick, move address, etc.  Instead the context
 does the job.  For example,
 <DL><DT><DD><TT><PRE>
-	MOVL	$1, R1
+	MOVL	<I>1, R1
 	MOVL	A0, R2
 	MOVW	SR, R3
 </PRE></TT></DL>
 generates official
-<TT>MOVEQ</TT>,
-<TT>MOVEA</TT>,
+</I><TT>MOVEQ</TT><I>,
+</I><TT>MOVEA</TT><I>,
 and
-<TT>MOVESR</TT>
+</I><TT>MOVESR</TT><I>
 instructions.
 A number of instructions do not have the syntax necessary to specify
 their entire capabilities.  Notable examples are the bitfield
 instructions, the
 multiply and divide instructions, etc.
 For a complete set of generated instruction names (in
-<TT>2a</TT>
+</I><TT>2a</TT><I>
 notation, not Motorola's) see the file
-<TT>/sys/src/cmd/2c/2.out.h</TT>.
+</I><TT>/sys/src/cmd/2c/2.out.h</TT><I>.
 Despite its name, this file contains an enumeration of the
 instructions that appear in the intermediate files generated
 by the compiler, which correspond exactly to lines of assembly language.
 </P>
-<P>
+</I><P>
 The MC68000 assembler,
 <TT>1a</TT>,
 is essentially the same, honoring the appropriate subset of the instructions
@@ -1175,7 +1175,7 @@ For example:
 <DL><DT><DD><TT><PRE>
 	MOVFL	CR(3), CR(0)
 	MOVFL	R3, CR(1)
-	MOVFL	R3, $7, CR
+	MOVFL	R3, 7, CR
 </PRE></TT></DL>
 They are also accepted in
 the conditional branch instruction, for example
@@ -1190,8 +1190,8 @@ in a similar way:
 <DL><DT><DD><TT><PRE>
 	MOVFL	FPSCR, F0
 	MOVFL	F0, FPSCR
-	MOVFL	F0, $7, FPSCR
-	MOVFL	$0, FPSCR(3)
+	MOVFL	F0, <I>7, FPSCR
+	MOVFL	</I>0, FPSCR(3)
 </PRE></TT></DL>
 producing
 <TT>mffs</TT>,
@@ -1282,16 +1282,16 @@ and
 <TT>R14</TT>
 when in another processor mode.
 Shifts and rotates in addressing modes are supported by binary operators
-<TT><<</TT>
+<TT>&lt;&lt;</TT>
 (logical left shift),
-<TT>>></TT>
+<TT>&gt;&gt;</TT>
 (logical right shift),
-<TT>-></TT>
+<TT>-&gt;</TT>
 (arithmetic right shift), and
-<TT>@></TT>
+<TT>@&gt;</TT>
 (rotate right); for example
-<TT>R7>>R2</TT>or
-<TT>R2@>2</TT>.
+<TT>R7&gt;&gt;R2</TT>or
+<TT>R2@&gt;2</TT>.
 The assembler does not support indexing by a shifted expression;
 only names can be doubly indexed.
 </P>
@@ -1351,9 +1351,8 @@ and
 <P>
 For details about this assembly language, which was built for the AMD 29240,
 look at the sources or examine compiler output.
-
 </P>
 <br>&#32;<br>
 <A href=http://www.lucent.com/copyright.html>
-Copyright</A> &#169; 2000 Lucent Technologies Inc.  All rights reserved.
+Copyright</A> &#169; 2004 Lucent Technologies Inc.  All rights reserved.
 </body></html>

+ 2052 - 438
sys/doc/auth.html

@@ -1,46 +1,172 @@
-<HEAD>
-<TITLE>Security in Plan 9</TITLE>
-<META content="text/html; charset=utf-8" http-equiv=Content-Type>
-</HEAD>
-<BODY BGCOLOR=WHITE>
-<h1>Security in Plan 9</h1>
-<EM>Russ Cox, MIT LCS<br>
+<html>
+<br><img src="-.19111510.gif"><br>
+<title>
+-
+</title>
+<body BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#330088" ALINK="#FF0044">
+<H1>Security in Plan 9
+</H1>
+<DL><DD><I>Russ Cox, MIT LCS<br>
+<br>
 Eric Grosse, Bell Labs<br>
+<br>
 Rob Pike, Bell Labs<br>
+<br>
 Dave Presotto, Avaya Labs and Bell Labs<br>
+<br>
 Sean Quinlan, Bell Labs<br>
-</EM><TT>{rsc,ehg,rob,presotto,seanq}@plan9.bell-labs.com<br>
-</TT><h4>ABSTRACT</h4>
-The security architecture of the Plan 9(tm) operating system has recently been redesigned to address some technical shortcomings. This redesign provided an opportunity also to make the system more convenient to use securely. Plan 9 has thus improved in two ways not usually seen together: it has become more secure <EM>and </EM>easier to use.
-  <P>
-The central component of the new architecture is a per-user self-contained agent called <TT>factotum</TT>. <TT>Factotum</TT> securely holds a copy of the user's keys and negotiates authentication protocols, on behalf of the user, with secure services around the network. Concentrating security code in a single program offers several advantages including: ease of update or repair to broken security software and protocols; the ability to run secure services at a lower privilege level; uniform management of keys for all services; and an opportunity to provide single sign on, even to unchanged legacy applications. <TT>Factotum</TT> has an unusual architecture: it is implemented as a Plan 9 file server. [[ To appear, in a slightly different form, in <EM>Proc. of the 2002 Usenix Security Symposium, </EM>San Francisco. ]]
-<H4>1. Introduction
-</H4>
-Secure computing systems face two challenges: first, they must employ sophisticated technology that is difficult to design and prove correct; and second, they must be easy for regular people to use. The question of ease of use is sometimes neglected, but it is essential: weak but easy-to-use security can be more effective than strong but difficult-to-use security if it is more likely to be used. People lock their front doors when they leave the house, knowing full well that a burglar is capable of picking the lock (or avoiding the door altogether); yet few would accept the cost and awkwardness of a bank vault door on the house even though that might reduce the probability of a robbery. A related point is that users need a clear model of how the security operates (if not how it actually provides security) in order to use it well; for example, the clarity of a lock icon on a web browser is offset by the confusing and typically insecure steps for installing X.509 certificates.
-  <P>
-The security architecture of the Plan 9 operating system [Pike95] has recently been redesigned to make it both more secure and easier to use. By <EM>security </EM>we mean three things: first, the business of authenticating users and services; second, the safe handling, deployment, and use of keys and other secret information; and third, the use of encryption and integrity checks to safeguard communications from prying eyes.
-  <P>
-The old security architecture of Plan 9 had several engineering problems in common with other operating systems. First, it had an inadequate notion of security domain. Once a user provided a password to connect to a local file store, the system required that the same password be used to access all the other file stores. That is, the system treated all network services as belonging to the same security domain.
-  <P>
-Second, the algorithms and protocols used in authentication, by nature tricky and difficult to get right, were compiled into the various applications, kernel modules, and file servers. Changes and fixes to a security protocol required that all components using that protocol needed to be recompiled, or at least relinked, and restarted.
-  <P>
-Third, the file transport protocol, 9P [Pike93], that forms the core of the Plan 9 system, had its authentication protocol embedded in its design. This meant that fixing or changing the authentication used by 9P required deep changes to the system. If someone were to find a way to break the protocol, the system would be wide open and very hard to fix.
-  <P>
-These and a number of lesser problems, combined with a desire for more widespread use of encryption in the system, spurred us to rethink the entire security architecture of Plan 9.<br>
-  <P>
-The centerpiece of the new architecture is an agent, called <TT>factotum</TT>, that handles the user's keys and negotiates all security interactions with system services and applications. Like a trusted assistant with a copy of the owner's keys, <TT>factotum</TT> does all the negotiation for security and authentication. Programs no longer need to be compiled with cryptographic code; instead they communicate with <TT>factotum</TT> agents that represent distinct entities in the cryptographic exchange, such as a user and server of a secure service. If a security protocol needs to be added, deleted, or modified, only <TT>factotum</TT> needs to be updated for all system services to be kept secure.
-  <P>
-Building on <TT>factotum</TT>, we modified secure services in the system to move user authentication code into <TT>factotum</TT>; made authentication a separable component of the file server protocol; deployed new security protocols; designed a secure file store, called <TT>secstore</TT>, to protect our keys but make them easy to get when they are needed; designed a new kernel module to support transparent use of Transport Layer Security (TLS) [RFC2246]; and began using encryption for all communications within the system. The overall architecture is illustrated in Figure 1a.
-<DL><DT><DD>
-<br><img src="-.2669382.gif"><br>
+<br>
+<TT>{rsc,ehg,rob,presotto,seanq}@plan9.bell-labs.com</TT>
+</I></DL>
+<DL><DD><H4>ABSTRACT</H4>
+The security architecture of the Plan 9(tm)
+operating system has recently been redesigned
+to address some technical shortcomings.
+This redesign provided an opportunity also to make the system more
+convenient to use securely.
+Plan 9 has thus improved in two ways not usually seen together:
+it has become more secure
+<I>and</I>
+easier to use.
+<br>&#32;<br>
+The central component of the new architecture is a per-user
+self-contained agent called
+<TT>factotum</TT>.
+<TT>Factotum</TT>
+securely holds a
+copy of the user's keys and negotiates authentication protocols, on
+behalf of the user, with secure services around the network.
+Concentrating security code in a single program offers several
+advantages including: ease of update or repair to broken security
+software and protocols; the ability to run secure services at a lower
+privilege level; uniform management of keys for all services; and an
+opportunity to provide single sign on, even to unchanged legacy
+applications.
+<TT>Factotum</TT>
+has an unusual architecture: it is implemented
+as a Plan 9 file server.
+<DL>
+<DT><DT>&#32;<DD>
+NOTE:<I> To appear, in a slightly different form, in
+Proc. of the 2002 Usenix Security Symposium,
+San Francisco.
+</I><DT>&#32;<DD></dl>
+<br>
 </DL>
+<H4>1 Introduction
+</H4>
+<br>&#32;<br>
+Secure computing systems face two challenges:
+first, they must employ sophisticated technology that is difficult to design
+and prove correct; and second,
+they must be easy for regular people to use.
+The question of ease of use is sometimes neglected, but it is essential:
+weak but easy-to-use security can be more effective than strong but
+difficult-to-use security if it is more likely to be used.
+People lock their front doors when they leave the house, knowing
+full well that a burglar is capable of picking the lock (or avoiding
+the door altogether); yet few would accept the cost and
+awkwardness of a bank vault door on the
+house even though that might reduce the probability of a robbery.
+A related point is that users need a clear model of how the security
+operates (if not how it actually provides security) in order to use it
+well; for example, the clarity of a lock icon on a web browser
+is offset by the confusing and typically insecure
+steps for installing X.509 certificates.
+<br>&#32;<br>
+The security architecture of the Plan 9
+operating system
+[Pike95]
+has recently been redesigned to make it both more secure
+and easier to use.
+By
+<I>security</I>
+we mean three things:
+first, the business of authenticating users and services;
+second, the safe handling, deployment, and use of keys
+and other secret information; and
+third, the use of encryption and integrity checks
+to safeguard communications
+from prying eyes.
+<br>&#32;<br>
+The old security architecture of Plan 9
+had several engineering problems in common with other operating systems.
+First, it had an inadequate notion of security domain.
+Once a user provided a password to connect to a local file store,
+the system required that the same password be used to access all the other file
+stores.
+That is, the system treated all network services as
+belonging to the same security domain. 
+<br>&#32;<br>
+Second, the algorithms and protocols used in authentication,
+by nature tricky and difficult to get right, were compiled into the
+various applications, kernel modules, and file servers.
+Changes and fixes to a security protocol
+required that all components using that protocol needed to be recompiled,
+or at least relinked, and restarted.
+<br>&#32;<br>
+Third, the file transport protocol, 9P
+[Pike93],
+that forms the core of
+the Plan 9 system, had its authentication protocol embedded in its design.
+This meant that fixing or changing the authentication used by 9P
+required deep changes to the system.
+If someone were to find a way to break the protocol, the system would
+be wide open and very hard to fix.
+<br>&#32;<br>
+These and a number of lesser problems, combined with a desire
+for more widespread use of encryption in the system, spurred us to
+rethink the entire security architecture of Plan 9.
+<br>&#32;<br>
+The centerpiece of the new architecture is an agent,
+called
+<TT>factotum</TT>,
+that handles the user's keys and negotiates all security
+interactions with system services and applications.
+Like a trusted assistant with a copy of the owner's keys,
+<TT>factotum</TT>
+does all the negotiation for security and authentication.
+Programs no longer need to be compiled with cryptographic
+code; instead they communicate with
+<TT>factotum</TT>
+agents
+that represent distinct entities in the cryptographic exchange,
+such as a user and server of a secure service.
+If a security protocol needs to be added, deleted, or modified,
+only
+<TT>factotum</TT>
+needs to be updated for all system services
+to be kept secure.
+<br>&#32;<br>
+Building on
+<TT>factotum</TT>,
+we modified
+secure services in the system to move
+user authentication code into
+<TT>factotum</TT>;
+made authentication a separable component of the file server protocol;
+deployed new security protocols;
+designed a secure file store,
+called
+<TT>secstore</TT>,
+to protect our keys but make them easy to get when they are needed;
+designed a new kernel module to support transparent use of 
+Transport Layer Security (TLS)
+[RFC2246];
+and began using encryption for all communications within the system.
+The overall architecture is illustrated in Figure 1a.
+<br><img src="-.19111511.gif"><br>
+<DL><DT><DD><TT><PRE>
+<br><img src="-.19111512.gif"><br>
+</PRE></TT></DL>
+<br>&#32;<br>
 Figure 1a.  Components of the security architecture.
 Each box is a (typically) separate machine; each ellipse a process.
-The ellipses labeled <I>F</I><I>X</I>
+n(11The ellipses labeled &lt;I&gt;F&lt;/I&gt;&lt;I&gt;X&lt;/I&gt;n(99
 are
 <TT>factotum</TT>
 processes; those labeled
-<I>P</I><I>X</I>
+n(11&lt;I&gt;P&lt;/I&gt;&lt;I&gt;X&lt;/I&gt;n(99
 are the pieces and proxies of a distributed program.
 The authentication server is one of several repositories for users' security information
 that
@@ -50,433 +176,1921 @@ processes consult as required.
 is a shared resource for storing private information such as keys;
 <TT>factotum</TT>
 consults it for the user during bootstrap.
-<P>
-Secure protocols and algorithms are well understood and are usually not the weakest link in a system's security. In practice, most security problems arise from buggy servers, confusing software, or administrative oversights. It is these practical problems that we are addressing. Although this paper describes the algorithms and protocols we are using, they are included mainly for concreteness. Our main intent is to present a simple security architecture built upon a small trusted code base that is easy to verify (whether by manual or automatic means), easy to understand, and easy to use.
-  <P>
-Although it is a subjective assessment, we believe we have achieved our goal of ease of use. That we have achieved our goal of improved security is supported by our plan to move our currently private computing environment onto the Internet outside the corporate firewall. The rest of this paper explains the architecture and how it is used, to explain why a system that is easy to use securely is also safe enough to run in the open network.
-<H4>2. An Agent for Security
-</H4>  <P>
-One of the primary reasons for the redesign of the Plan 9 security infrastructure was to remove the authentication method both from the applications and from the kernel. Cryptographic code is large and intricate, so it should be packaged as a separate component that can be repaired or modified without altering or even relinking applications and services that depend on it. If a security protocol is broken, it should be trivial to repair, disable, or replace it on the fly. Similarly, it should be possible for multiple programs to use a common security protocol without embedding it in each program.
-  <P>
-Some systems use dynamically linked libraries (DLLs) to address these configuration issues. The problem with this approach is that it leaves security code in the same address space as the program using it. The interactions between the program and the DLL can therefore accidentally or deliberately violate the interface, weakening security. Also, a program using a library to implement secure services must run at a privilege level necessary to provide the service; separating the security to a different program makes it possible to run the services at a weaker privilege level, isolating the privileged code to a single, more trustworthy component.
-  <P>
-Following the lead of the SSH agent [Ylon96], we give each user an agent process responsible for holding and using the user's keys. The agent program is called <TT>factotum</TT> because of its similarity to the proverbial servant with the power to act on behalf of his master because he holds the keys to all the master's possessions. It is essential that <TT>factotum</TT> keep the keys secret and use them only in the owner's interest. Later we'll discuss some changes to the kernel to reduce the possibility of <TT>factotum</TT> leaking information inadvertently.
-  <P>
-<TT>Factotum</TT> is implemented, like most Plan 9 services, as a file server. It is conventionally mounted upon the directory <TT>/mnt/factotum</TT>, and the files it serves there are analogous to virtual devices that provide access to, and control of, the services of the <TT>factotum</TT>. The next few sections describe the design of <TT>factotum</TT> and how it operates with the other pieces of Plan 9 to provide security services.
-<H4>2.1. Logging in
+<br>&#32;<br>
+<br><img src="-.19111513.gif"><br>
+<br>&#32;<br>
+Secure protocols and algorithms are well understood
+and are usually not the weakest link in a system's security.
+In practice, most security problems arise from buggy servers,
+confusing software, or administrative oversights.
+It is these practical problems that we are addressing.
+Although this paper describes the algorithms and protocols we are using,
+they are included mainly for concreteness.
+Our main intent is to present a simple security architecture built
+upon a small trusted code base that is easy to verify (whether by manual or
+automatic means), easy to understand, and easy to use.
+<br>&#32;<br>
+Although it is a subjective assessment,
+we believe we have achieved our goal of ease of use.
+That we have achieved
+our goal of improved security is supported by our plan to
+move our currently private computing environment onto the Internet
+outside the corporate firewall.
+The rest of this paper explains the architecture and how it is used,
+to explain why a system that is easy to use securely is also safe
+enough to run in the open network.
+<H4>2 An Agent for Security
 </H4>
-To make the discussions that follow more concrete, we begin with a couple of examples showing how the Plan 9 security architecture appears to the user. These examples both involve a user <TT>gre</TT> logging in after booting a local machine. The user may or may not have a secure store in which all his keys are kept. If he does, <TT>factotum</TT> will prompt him for the password to the secure store and obtain keys from it, prompting only when a key isn't found in the store. Otherwise, <TT>factotum</TT> must prompt for each key.
-  <P>
-In the typescripts, <TT>\n</TT> represents a literal newline character typed to force a default response. User input is in italics, and long lines are folded and indented to fit.<br>
-  <P>
-This first example shows a user logging in without help from the secure store. First, <TT>factotum</TT> prompts for a user name that the local kernel will use:
-<pre>
-    user[none]: <em>gre</em>
-</pre>
-(Default responses appear in square brackets.) The kernel then starts accessing local resources and requests, through <TT>factotum</TT>, a user/password pair to do so:
-<pre>
-    !Adding key: dom=cs.bell-labs.com proto=p9sk1
-    user[gre]: <em>\n</em>
-    password: ****
-</pre>
-Now the user is logged in to the local system, and the mail client starts up:
-<pre>
-    !Adding key: proto=apop server=plan9.bell-labs.com
-    user[gre]: <em>\n</em>
-    password: <em>****</em>
-</pre>
-<TT>Factotum</TT> is doing all the prompting and the applications being started are not even touching the keys. Note that it's always clear which key is being requested.<br>
-  <P>
-Now consider the same login sequence, but in the case where <TT>gre</TT> has a secure store account:
-<pre>
-    user[none]: gre
-    secstore password: <em>*********</em>
-    STA PIN+SecurID: <em>*********</em>
-</pre>
-That's the last <TT>gre </TT>will hear from <TT>factotum </TT>unless an attempt is made to contact a system for which no key is kept in the secure store.<br>
-<H4>2.2. The factotum
+<br>&#32;<br>
+One of the primary reasons for the redesign of the Plan 9
+security infrastructure was to remove the authentication
+method both from the applications and from the kernel.
+Cryptographic code
+is large and intricate, so it should
+be packaged as a separate component that can be repaired or
+modified without altering or even relinking applications
+and services that depend on it.
+If a security protocol is broken, it should be trivial to repair,
+disable, or replace it on the fly.
+Similarly, it should be possible for multiple programs to use
+a common security protocol without embedding it in each program.
+<br>&#32;<br>
+Some systems use dynamically linked libraries (DLLs) to address these configuration issues.
+The problem with this approach is that it leaves
+security code in the same address space as the program using it.
+The interactions between the program and the DLL
+can therefore accidentally or deliberately violate the interface,
+weakening security.
+Also, a program using a library to implement secure services
+must run at a privilege level necessary to provide the service;
+separating the security to a different program makes it possible
+to run the services at a weaker privilege level, isolating the
+privileged code to a single, more trustworthy component.
+<br>&#32;<br>
+Following the lead of the SSH agent
+[Ylon96],
+we give each user
+an agent process responsible
+for holding and using the user's keys.
+The agent program is called
+<TT>factotum</TT>
+because of its similarity to the proverbial servant with the
+power to act on behalf of his master because he holds the
+keys to all the master's possessions.  It is essential that
+<TT>factotum</TT>
+keep the keys secret and use them only in the owner's interest.
+Later we'll discuss some changes to the kernel to reduce the possibility of
+<TT>factotum</TT>
+leaking information inadvertently.
+<br>&#32;<br>
+<TT>Factotum</TT>
+is implemented, like most Plan 9 services, as a file server.
+It is conventionally mounted upon the directory
+<TT>/mnt/factotum</TT>,
+and the files it serves there are analogous to virtual devices that provide access to,
+and control of, the services of the
+<TT>factotum</TT>.
+The next few sections describe the design of
+<TT>factotum</TT>
+and how it operates with the other pieces of Plan 9 to provide
+security services.
+<H4>2.1 Logging in
 </H4>
-Each computer running Plan 9 has one user id that owns all the resources on that system -- the scheduler, local disks, network interfaces, etc. That user, the <EM>host owner</EM>, is the closest analogue in Plan 9 to a Unix <TT>root</TT> account (although it is far weaker; rather than having special powers, as its name implies the host owner is just a regular user that happens to own the resources of the local machine). On a single-user system, which we call a terminal, the host owner is the id of the terminal's user. Shared servers such as CPU servers normally have a pseudo-user that initially owns all resources. At boot time, the Plan 9 kernel starts a <TT>factotum</TT> executing as, and therefore with the privileges of, the host owner.
-  <P>
-New processes run as the same user as the process which created them. When a process must take on the identity of a new user, such as to provide a login shell on a shared CPU server, it does so by proving to the host owner's <TT>factotum</TT> that it is authorized to do so. This is done by running an authentication protocol with <TT>factotum</TT> to prove that the process has access to secret information which only the new user should possess. For example, consider the setup in Figure 1a. If a user on the terminal wants to log in to the CPU server using the Plan 9 <TT>cpu</TT> service [Pike93], then <EM>PT </EM>might be the <TT>cpu</TT> client program and <EM>PC </EM>the <TT>cpu</TT> server. Neither <EM>PC </EM>nor <EM>PT </EM>knows the details of the authentication. They do need to be able to shuttle messages back and forth between the two <TT>factotums</TT>, but this is a generic function easily performed without knowing, or being able to extract, secrets in the messages. <EM>PT </EM>will make a network connection to <EM>PC</EM>. <EM>PT </EM>and <EM>PC </EM>will then relay messages between the <TT>factotum</TT> owned by the user, <EM>FT</EM>, and the one owned by the CPU server, <EM>FC</EM>, until mutual authentication has been established. Later sections describe the RPC between <TT>factotum</TT> and applications and the library functions to support proxy operations.
-  <P>
-The kernel always uses a single local instance of <TT>factotum</TT>, running as the host owner, for its authentication purposes, but a regular user may start other <TT>factotum</TT> agents. In fact, the <TT>factotum</TT> representing the user need not be running on the same machine as its client. For instance, it is easy for a user on a CPU server, through standard Plan 9 operations, to replace the <TT>/mnt/factotum</TT> in the user's private file name space on the server with a connection to the <TT>factotum</TT> running on the terminal. (The usual file system permissions prevent interlopers from doing so maliciously.) This permits secure operations on the CPU server to be transparently validated by the user's own <TT>factotum</TT>, so secrets need never leave the user's terminal. The SSH agent [Ylon96] does much the same with special SSH protocol messages, but an advantage to making our agent a file system is that we need no new mechanism to access our remote agent; remote file access is sufficient.
-  <P>
-Within <TT>factotum</TT>, each protocol is implemented as a state machine with a generic interface, so protocols are in essence pluggable modules, easy to add, modify, or drop. Writing a message to and reading a message from <TT>factotum</TT> each require a separate RPC and result in a single state transition. Therefore <TT>factotum</TT> always runs to completion on every RPC and never blocks waiting for input during any authentication. Moreover, the number of simultaneous authentications is limited only by the amount of memory we're willing to dedicate to representing the state machines.
-  <P>
-Authentication protocols are implemented only within <TT>factotum</TT>, but adding and removing protocols does require relinking the binary, so <TT>factotum</TT> processes (but no others) need to be restarted in order to take advantage of new or repaired protocols.<br>
-  <P>
-At the time of writing, <TT>factotum</TT> contains authentication modules for the Plan 9 shared key protocol (p9sk1), SSH's RSA authentication, passwords in the clear, APOP, CRAM, PPP's CHAP, Microsoft PPP's MSCHAP, and VNC's challenge/response.<br>
-<H4>2.3. Local capabilities
+<br>&#32;<br>
+To make the discussions that follow more concrete,
+we begin with a couple of examples showing how the
+Plan 9 security architecture appears to the user.
+These examples both involve a user
+<TT>gre</TT>
+logging in after booting a local machine.
+The user may or may not have a secure store in which
+all his keys are kept.
+If he does,
+<TT>factotum</TT>
+will prompt him for the password to the secure store
+and obtain keys from it, prompting only when a key
+isn't found in the store.
+Otherwise,
+<TT>factotum</TT>
+must prompt for each key.
+<br>&#32;<br>
+In the typescripts, \n
+represents a literal newline
+character typed to force a default response.
+User input is in italics, and
+long lines are folded and indented to fit.
+<br>&#32;<br>
+This first example shows a user logging in without
+help from the secure store.
+First,
+<TT>factotum</TT>
+prompts for a user name that the local kernel
+will use:
+<DL><DT><DD><TT><PRE>
+user[none]: gre
+</PRE></TT></DL>
+(Default responses appear in square brackets.)
+The kernel then starts accessing local resources
+and requests, through
+<TT>factotum</TT>,
+a user/password pair to do so:
+<DL><DT><DD><TT><PRE>
+!Adding key: dom=cs.bell-labs.com
+    proto=p9sk1
+user[gre]: \n
+password: ****
+</PRE></TT></DL>
+Now the user is logged in to the local system, and
+the mail client starts up:
+<DL><DT><DD><TT><PRE>
+!Adding key: proto=apop
+    server=plan9.bell-labs.com
+user[gre]: \n
+password: ****
+</PRE></TT></DL>
+<TT>Factotum</TT>
+is doing all the prompting and the applications
+being started are not even touching the keys.
+Note that it's always clear which key is being requested.
+<br>&#32;<br>
+Now consider the same login sequence, but in the case where
+<TT>gre</TT>
+has a secure store account:
+<DL><DT><DD><TT><PRE>
+user[none]: gre
+secstore password: *********
+STA PIN+SecurID: *********
+</PRE></TT></DL>
+That's the last
+<TT>gre</TT>
+will hear from
+<TT>factotum</TT>
+unless an attempt is made to contact
+a system for which no key is kept in the secure store.
+<H4>2.2 The factotum
+</H4>
+<br>&#32;<br>
+Each computer running Plan 9 has one user id that owns all the
+resources on that system &#173; the scheduler, local disks,
+network interfaces, etc.
+That user, the
+<I>host owner</I>,
+is the closest analogue in Plan 9 to a Unix
+<TT>root</TT>
+account (although it is far weaker;
+rather than having special powers, as its name implies the host owner
+is just a regular user that happens to own the
+resources of the local machine).
+On a single-user system, which we call a terminal,
+the host owner is the id of the terminal's user.
+Shared servers such as CPU servers normally have a pseudo-user
+that initially owns all resources.
+At boot time, the Plan 9 kernel starts a
+<TT>factotum</TT>
+executing as, and therefore with the privileges of,
+the host owner.
+<br>&#32;<br>
+New processes run as
+the same user as the process which created them.
+When a process must take on the identity of a new user,
+such as to provide a login shell
+on a shared CPU server,
+it does so by proving to the host owner's
+<TT>factotum</TT>
+that it is
+authorized to do so.
+This is done by running an
+authentication protocol with
+<TT>factotum</TT>
+to
+prove that the process has access to secret information
+which only the new user should possess.
+For example, consider the setup in Figure 1a.
+If a user on the terminal
+wants to log in to the CPU server using the
+Plan 9
+<TT>cpu</TT>
+service
+[Pike93],
+then
+n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;T&lt;/I&gt;11n(99
+might be the
+<TT>cpu</TT>
+client program and
+n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99
+the
+<TT>cpu</TT>
+server.
+n(11Neither 11&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99 nor 11&lt;I&gt;P&lt;/I&gt;&lt;I&gt;T&lt;/I&gt;11n(99
+knows the details of the authentication.
+They
+do need to be able to shuttle messages back and
+forth between the two
+<TT>factotums</TT>,
+but this is
+a generic function easily performed without
+knowing, or being able to extract, secrets in
+the messages.
+n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;T&lt;/I&gt;11n(99
+n(11will make a network connection to 11&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99.
+n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;T&lt;/I&gt;11n(99
+and
+n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99
+will then relay messages between
+the
+<TT>factotum</TT>
+n(11owned by the user, 11&lt;I&gt;F&lt;/I&gt;&lt;I&gt;T&lt;/I&gt;11n(99,
+n(11and the one owned by the CPU server, 11&lt;I&gt;F&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99,
+until mutual authentication has been established.
+Later
+sections describe the RPC between
+<TT>factotum</TT>
+and
+applications and the library functions to support proxy operations.
+<br>&#32;<br>
+The kernel always uses a single local instance of
+<TT>factotum</TT>,
+running as the
+host owner, for
+its authentication purposes, but
+a regular user may start other
+<TT>factotum</TT>
+agents.
+In fact, the
+<TT>factotum</TT>
+representing the user need not be
+running on the same machine as its client.
+For instance, it is easy for a user on a CPU server,
+through standard Plan 9 operations,
+to replace the
+<TT>/mnt/factotum</TT>
+in the user's private file name space on the server
+with a connection to the
+<TT>factotum</TT>
+running on the terminal.
+(The usual file system permissions prevent interlopers
+from doing so maliciously.)
+This permits secure operations on the CPU server to be
+transparently validated by the user's own
+<TT>factotum</TT>,
+so
+secrets need never leave the user's terminal.
+The SSH agent
+[Ylon96]
+does much the
+same with special SSH protocol messages, but
+an advantage to making our agent a file system
+is that we need no new mechanism to access our remote
+agent; remote file access is sufficient.
+<br>&#32;<br>
+Within
+<TT>factotum</TT>,
+each protocol is implemented as a state
+machine with a generic interface, so protocols are in
+essence pluggable modules, easy to add, modify, or drop.
+Writing a message to and reading a message from
+<TT>factotum</TT>
+each require a separate RPC and result in
+a single state transition.
+Therefore
+<TT>factotum</TT>
+always runs to completion on every RPC and never blocks
+waiting for input during any authentication.
+Moreover, the number of simultaneous
+authentications is limited only by the amount of memory we're
+willing to dedicate to representing the state machines.
+<br>&#32;<br>
+Authentication protocols are implemented only
+within
+<TT>factotum</TT>,
+but adding and removing
+protocols does require relinking the binary, so
+<TT>factotum</TT>
+processes (but no others)
+need to be restarted in order to take advantage of
+new or repaired protocols.
+<br>&#32;<br>
+At the time of writing, 
+<TT>factotum</TT>
+contains authentication
+modules for the Plan 9 shared key protocol (p9sk1),
+SSH's RSA authentication, passwords in the clear, APOP, CRAM, PPP's CHAP,
+Microsoft PPP's MSCHAP, and VNC's challenge/response.
+<H4>2.3 Local capabilities
 </H4>
-A capability system, managed by the kernel, is used to empower <TT>factotum</TT> to grant permission to another process to change its user id. A kernel device driver implements two files, <TT>/dev/caphash</TT> and <TT>/dev/capuse</TT>. The write-only file <TT>/dev/caphash</TT> can be opened only by the host owner, and only once. <TT>Factotum</TT> opens this file immediately after booting.
-  <P>
-To use the files, <TT>factotum</TT> creates a string of the form <EM>userid1</EM><TT>@</TT><EM>userid2</EM><TT>@</TT><EM>random-string</EM>, uses SHA1 HMAC to hash <EM>userid1</EM><TT>@</TT><EM>userid2 </EM>with key <EM>random-string</EM>, and writes that hash to <TT>/dev/caphash</TT>. <TT>Factotum</TT> then passes the original string to another process on the same machine, running as user <EM>userid1</EM>, which writes the string to <TT>/dev/capuse</TT>. The kernel hashes the string and looks for a matching hash in its list. If it finds one, the writing process's user id changes from <EM>userid1 </EM>to <EM>userid2</EM>. Once used, or if a timeout expires, the capability is discarded by the kernel.
-  <P>
-The capabilities are local to the machine on which they are created. Hence a <TT>factotum</TT> running on one machine cannot pass capabilities to processes on another and expect them to work.<br>
-<H4>2.4. Keys
+<br>&#32;<br>
+A capability system, managed by the kernel, is used to empower
+<TT>factotum</TT>
+to grant permission to another process to change its user id.
+A
+kernel device driver
+implements two files,
+<TT>/dev/caphash</TT>
+and
+<TT>/dev/capuse</TT>.
+The write-only file
+<TT>/dev/caphash</TT>
+can be opened only by the host owner, and only once.
+<TT>Factotum</TT>
+opens this file immediately after booting.
+<br>&#32;<br>
+To use the files,
+<TT>factotum</TT>
+creates a string of the form
+<I>userid1</I><TT>@</TT><I>userid2</I><TT>@</TT><I>random-string</I><TT>,
+uses SHA1 HMAC to hash
+</TT><I>userid1</I><TT>@</TT><I>userid2</I><TT>
+with key
+</TT><I>random-string</I><TT>,
+and writes that hash to
+</TT><TT>/dev/caphash</TT><TT>.
+</TT><TT>Factotum</TT><TT>
+then passes the original string to another
+process on the same machine, running
+as user
+</TT><I>userid1</I><TT>,
+which
+writes the string to
+</TT><TT>/dev/capuse</TT><TT>.
+The kernel hashes the string and looks for
+a matching hash in its list.
+If it finds one,
+the writing process's user id changes from
+</TT><I>userid1</I><TT>
+to
+</TT><I>userid2</I><TT>.
+Once used, or if a timeout expires,
+the capability is discarded by the kernel.
+</TT><br>&#32;<br>
+The capabilities are local to the machine on which they are created.
+Hence a
+<TT>factotum</TT>
+running on one machine cannot pass capabilities
+to processes on another and expect them to work.
+<H4>2.4 Keys
 </H4>
-We define the word <EM>key </EM>to mean not only a secret, but also a description of the context in which that secret is to be used: the protocol, server, user, etc. to which it applies. That is, a key is a combination of secret and descriptive information used to authenticate the identities of parties transmitting or receiving information. The set of keys used in any authentication depends both on the protocol and on parameters passed by the program requesting the authentication.
-  <P>
-Taking a tip from SDSI [RiLa], which represents security information as textual S-expressions, keys in Plan 9 are represented as plain UTF-8 text. Text is easily understood and manipulated by users. By contrast, a binary or other cryptic format can actually reduce overall security. Binary formats are difficult for users to examine and can only be cracked by special tools, themselves poorly understood by most users. For example, very few people know or understand what's inside their X.509 certificates. Most don't even know where in the system to find them. Therefore, they have no idea what they are trusting, and why, and are powerless to change their trust relationships. Textual, centrally stored and managed keys are easier to use and safer.
-  <P>
-Plan 9 has historically represented databases as attribute/value pairs, since they are a good foundation for selection and projection operations. <TT>Factotum</TT> therefore represents the keys in the format <EM>attribute</EM><TT>=</TT><EM>value</EM>, where <EM>attribute </EM>is an identifier, possibly with a single-character prefix, and <EM>value </EM>is an arbitrary quoted string. The pairs themselves are separated by white space. For example, a Plan 9 key and an APOP key might be represented like this:
-<pre>
-    dom=bell-labs.com proto=p9sk1 user=gre !password='don''t tell'
-    proto=apop server=x.y.com user=gre !password='open sesame'
-</pre>
-If a value is empty or contains white space or single quotes, it must be quoted; quotes are represented by doubled single quotes. Attributes that begin with an exclamation mark (<TT>!</TT>) are considered <EM>secret</EM>. <TT>Factotum</TT> will never let a secret value escape its address space and will suppress keyboard echo when asking the user to type one.
-  <P>
-A program requesting authentication selects a key by providing a <EM>query</EM>, a list of elements to be matched by the key. Each element in the list is either an <EM>attribute</EM><TT>=</TT><EM>value </EM>pair, which is satisfied by keys with exactly that pair; or an attribute followed by a question mark, <EM>attribute</EM><TT>?</TT>, which is satisfied by keys with some pair specifying the attribute. A key matches a query if every element in the list is satisfied. For instance, to select the APOP key in the previous example, an APOP client process might specify the query
-<DL><DT><DD><TT>server=x.y.com proto=apop<br>
-</TT></DL>Internally, <TT>factotum</TT>'s APOP module would add the requirements of having <TT>user </TT>and <TT>!password </TT>attributes, forming the query<br>
-<DL><DT><DD><TT>server=x.y.com proto=apop user? !password?<br>
-</TT></DL>when searching for an appropriate key.<br>
-  <P>
-<TT>Factotum</TT> modules expect keys to have some well-known attributes. For instance, the <TT>proto</TT> attribute specifies the protocol module responsible for using a particular key, and protocol modules may expect other well-known attributes (many expect keys to have <TT>!password</TT> attributes, for example). Additional attributes can be used as comments or for further discrimination without intervention by <TT>factotum</TT>; for example, the APOP and IMAP mail clients conventionally include a <TT>server</TT> attribute to select an appropriate key for authentication.
-  <P>
-Unlike in SDSI, keys in Plan 9 have no nested structure. This design keeps the representation simple and straightforward. If necessary, we could add a nested attribute or, in the manner of relational databases, an attribute that selects another tuple, but so far the simple design has been sufficient.
-  <P>
-A simple common structure for all keys makes them easy for users to administer, but the set of attributes and their interpretation is still protocol-specific and can be subtle. Users may still need to consult a manual to understand all details. Many attributes (<TT>proto</TT>, <TT>user</TT>, <TT>password</TT>, <TT>server</TT>) are self-explanatory and our short experience has not uncovered any particular difficulty in handling keys. Things will likely get messier, however, when we grapple with public keys and their myriad components.
-<H4>2.5. Protecting keys
+<br>&#32;<br>
+We define the word
+<I>key</I>
+to mean not only a secret, but also a description of the
+context in which that secret is to be used: the protocol,
+server, user, etc. to which it applies.
+That is,
+a key is a combination of secret and descriptive information
+used to authenticate the identities of parties
+transmitting or receiving information.
+The set of keys used
+in any authentication depends both on the protocol and on
+parameters passed by the program requesting the authentication.
+<br>&#32;<br>
+Taking a tip from SDSI
+[RiLa],
+which represents security information as textual S-expressions,
+keys in Plan 9 are represented as plain UTF-8 text.
+Text is easily
+understood and manipulated by users.
+By contrast,
+a binary or other cryptic format
+can actually reduce overall security.
+Binary formats are difficult for users to examine and can only be
+cracked by special tools, themselves poorly understood by most users.
+For example, very few people know or understand what's inside
+their X.509 certificates.
+Most don't even know where in the system to
+find them.
+Therefore, they have no idea what they are trusting, and why, and
+are powerless to change their trust relationships.
+Textual, centrally stored and managed keys are easier to use and safer.
+<br>&#32;<br>
+Plan 9 has historically represented databases as attribute/value pairs,
+since they are a good foundation for selection and projection operations.
+<TT>Factotum</TT>
+therefore represents
+the keys in the format
+<I>attribute</I><TT>=</TT><I>value</I><TT>,
+where
+</TT><I>attribute</I><TT>
+is an identifier, possibly with a single-character prefix, and
+</TT><I>value</I><TT>
+is an arbitrary quoted string.
+The pairs themselves are separated by white space.
+For example, a Plan 9 key and an APOP key
+might be represented like this:
+<DL><DT><DD><TT><PRE>
+dom=bell-labs.com proto=p9sk1 user=gre
+	!password='don''t tell'
+proto=apop server=x.y.com user=gre
+	!password='open sesame'
+</PRE></TT></DL>
+If a value is empty or contains white space or single quotes, it must be quoted;
+quotes are represented by doubled single quotes.
+Attributes that begin with an exclamation mark
+(</TT><TT>!</TT><TT>)
+are considered
+</TT><I>secret</I><TT>.
+</TT><TT>Factotum</TT><TT>
+will never let a secret value escape its address space
+and will suppress keyboard echo when asking the user to type one.
+</TT><br>&#32;<br>
+A program requesting authentication selects a key
+by providing a
+<I>query</I>,
+a list of elements to be matched by the key.
+Each element in the list is either an
+<I>attribute</I><TT>=</TT><I>value</I><TT>
+pair, which is satisfied by keys with
+exactly that pair;
+or an attribute followed by a question mark,
+</TT><I>attribute</I><TT>?</TT><I>,
+which is satisfied by keys with some pair specifying
+the attribute.
+A key matches a query if every element in the list
+is satisfied.
+For instance, to select the APOP key in the previous example,
+an APOP client process might specify the query
+<DL><DT><DD><TT><PRE>
+server=x.y.com proto=apop
+</PRE></TT></DL>
+Internally,
+</I><TT>factotum</TT><I>'s
+APOP module would add the requirements of
+having
+</I><TT>user</TT><I>
+and
+</I><TT>!password</TT><I>
+attributes, forming the query
+<DL><DT><DD><TT><PRE>
+server=x.y.com proto=apop user? !password?
+</PRE></TT></DL>
+when searching for an appropriate key.
+</I><br>&#32;<br>
+<TT>Factotum</TT>
+modules expect keys to have some well-known attributes.
+For instance, the
+<TT>proto</TT>
+attribute specifies the protocol module
+responsible for using a particular key,
+and protocol modules may expect other well-known attributes
+(many expect keys to have
+<TT>!password</TT>
+attributes, for example).
+Additional attributes can be used as comments or for
+further discrimination without intervention by 
+<TT>factotum</TT>;
+for example, the APOP and IMAP mail clients conventionally
+include a
+<TT>server</TT>
+attribute to select an appropriate key for authentication.
+<br>&#32;<br>
+Unlike in SDSI,
+keys in Plan 9 have no nested structure.  This design
+keeps the representation simple and straightforward.
+If necessary, we could add a nested attribute
+or, in the manner of relational databases, an attribute that
+selects another tuple, but so far the simple design has been sufficient.
+<br>&#32;<br>
+A simple common structure for all keys makes them easy for users
+to administer,
+but the set of attributes and their interpretation is still
+protocol-specific and can be subtle.
+Users may still
+need to consult a manual to understand all details.
+Many attributes
+(<TT>proto</TT>,
+<TT>user</TT>,
+<TT>password</TT>,
+<TT>server</TT>)
+are self-explanatory and our short experience
+has not uncovered any particular difficulty in handling keys.
+Things
+will likely get messier, however,
+when we grapple with public
+keys and their myriad components.
+<H4>2.5 Protecting keys
 </H4>
-Secrets must be prevented from escaping <TT>factotum</TT>. There are a number of ways they could leak: another process might be able to debug the agent process, the agent might swap out to disk, or the process might willingly disclose the key. The last is the easiest to avoid: secret information in a key is marked as such, and whenever <TT>factotum</TT> prints keys or queries for new ones, it is careful to avoid displaying secret information. (The only exception to this is the ``plaintext password'' protocol, which consists of sending the values of the <TT>user</TT> and <TT>!password</TT> attributes. Only keys tagged with <TT>proto=pass</TT> can have their passwords disclosed by this mechanism.)
-  <P>
-Preventing the first two forms of leakage requires help from the kernel. In Plan 9, every process is represented by a directory in the <TT>/proc</TT> file system. Using the files in this directory, other processes could (with appropriate access permission) examine <TT>factotum</TT>'s memory and registers. <TT>Factotum</TT> is protected from processes of other users by the default access bits of its <TT>/proc</TT> directory. However, we'd also like to protect the agent from other processes owned by the same user, both to avoid honest mistakes and to prevent an unattended terminal being exploited to discover secret passwords. To do this, we added a control message to <TT>/proc</TT> called <TT>private</TT>. Once the <TT>factotum</TT> process has written <TT>private</TT> to its <TT>/proc/</TT><EM>pid</EM><TT>/ctl</TT> file, no process can access <TT>factotum</TT>'s memory through <TT>/proc</TT>. (Plan 9 has no other mechanism, such as <TT>/dev/kmem</TT>, for accessing a process's memory.)
-  <P>
-Similarly, the agent's address space should not be swapped out, to prevent discovering unencrypted keys on the swapping media. The <TT>noswap</TT> control message in <TT>/proc</TT> prevents this scenario. Neither <TT>private</TT> nor <TT>noswap</TT> is specific to <TT>factotum</TT>. User-level file servers such as <TT>dossrv</TT>, which interprets FAT file systems,
-could use <TT>noswap</TT>
+<br>&#32;<br>
+Secrets must be prevented from escaping
+<TT>factotum</TT>.
+There are a number of ways they could leak:
+another process might be able to debug the agent process, the
+agent might swap out to disk, or the process might willingly
+disclose the key.
+The last is the easiest to avoid:
+secret information in a key is marked
+as such, and
+whenever
+<TT>factotum</TT>
+prints keys or queries for new
+ones, it is careful to avoid displaying secret information.
+(The only exception to this is the
+``plaintext password'' protocol, which consists
+of sending the values of the
+<TT>user</TT>
+and
+<TT>!password</TT>
+attributes.
+Only keys tagged with
+<TT>proto=pass</TT>
+can have their passwords disclosed by this mechanism.)
+<br>&#32;<br>
+Preventing the first two forms of leakage
+requires help from the kernel.
+In Plan 9, every process is
+represented by a directory in the
+<TT>/proc</TT>
+file system.
+Using the files in this directory,
+other processes could (with appropriate access permission) examine
+<TT>factotum</TT>'s
+memory and registers.
+<TT>Factotum</TT>
+is protected from processes of other users
+by the default access bits of its
+<TT>/proc</TT>
+directory.
+However, we'd also like to protect the
+agent from other processes owned by the same user,
+both to avoid honest mistakes and to prevent
+an unattended terminal being
+exploited to discover secret passwords.
+To do this, we added a control message to
+<TT>/proc</TT>
+called
+<TT>private</TT>.
+Once the
+<TT>factotum</TT>
+process has written
+<TT>private</TT>
+to its
+<TT>/proc/</TT><I>pid</I><TT>/ctl</TT><I>
+file, no process can access
+</I><TT>factotum</TT><I>'s
+memory
+through
+</I><TT>/proc</TT><I>.
+(Plan 9 has no other mechanism, such as
+</I><TT>/dev/kmem</TT><I>,
+for accessing a process's memory.)
+</I><br>&#32;<br>
+Similarly, the agent's address space should not be
+swapped out, to prevent discovering unencrypted
+keys on the swapping media.
+The
+<TT>noswap</TT>
+control message in
+<TT>/proc</TT>
+prevents this scenario.
+Neither
+<TT>private</TT>
+nor
+<TT>noswap</TT>
+is specific to
+<TT>factotum</TT>.
+User-level file servers such as
+<TT>dossrv</TT>,
+which interprets FAT file systems,
+could use
+<TT>noswap</TT>
 to keep their buffer caches from being
 swapped to disk.
-  <P>
-Despite our precautions, attackers might still find a way to gain access to a process running as the host owner on a machine. Although they could not directly access the keys, attackers could use the local <TT>factotum</TT> to perform authentications for them. In the case of some keys, for example those locking bank accounts, we want a way to disable or at least detect such access. That is the role of the <TT>confirm</TT> attribute in a key. Whenever a key with a <TT>confirm</TT> attribute is accessed, the local user must confirm use of the key via a local GUI. The next section describes the actual mechanism.
-  <P>
-We have not addressed leaks possible as a result of someone rebooting or resetting a machine running <TT>factotum</TT>. For example, someone could reset a machine and reboot it with a debugger instead of a kernel, allowing them to examine the contents of memory and find keys. We have not found a satisfactory solution to this problem.
-<H4>2.6. Factotum transactions
+<br>&#32;<br>
+Despite our precautions, attackers might still
+find a way to gain access to a process running as the host
+owner on a machine.
+Although they could not directly
+access the keys, attackers could use the local
+<TT>factotum</TT>
+to perform authentications for them.
+In the case
+of some keys, for example those locking bank
+accounts, we want a way to disable or at least
+detect such access.
+That is the role of the
+<TT>confirm</TT>
+attribute in a key.
+Whenever a key with a
+<TT>confirm</TT>
+attribute is accessed, the local user must
+confirm use of the key via a local GUI.
+The next section describes the actual mechanism.
+<br>&#32;<br>
+We have not addressed leaks possible as a result of
+someone rebooting or resetting a machine running
+<TT>factotum</TT>.
+For example, someone could reset a machine
+and reboot it with a debugger instead of a kernel,
+allowing them to examine the contents of memory
+and find keys.  We have not found a satisfactory
+solution to this problem.
+<H4>2.6 Factotum transactions
 </H4>
-External programs manage <TT>factotum</TT>'s internal key state through its file interface, writing textual <TT>key</TT> and <TT>delkey</TT> commands to the <TT>/mnt/factotum/ctl</TT> file. Both commands take a list of attributes as an argument. <TT>Key</TT> creates a key with the given attributes, replacing any extant key with an identical set of public attributes. <TT>Delkey</TT> deletes all keys that match the given set of attributes. Reading the <TT>ctl</TT> file returns a list of keys, one per line, displaying only public attributes. The following example illustrates these interactions.
-<pre>
-    % cd /mnt/factotum
-    % ls -l
-    -lrw------- gre gre 0 Jan 30 22:17 confirm
-    --rw------- gre gre 0 Jan 30 22:17 ctl
-    -lr-------- gre gre 0 Jan 30 22:17 log
-    -lrw------- gre gre 0 Jan 30 22:17 needkey
-    --r--r--r-- gre gre 0 Jan 30 22:17 proto
-    --rw-rw-rw- gre gre 0 Jan 30 22:17 rpc
-    % cat &gt;ctl
-    key dom=bell-labs.com proto=p9sk1 user=gre !password='don''t tell'
-    key proto=apop server=x.y.com user=gre !password='bite me'
-    ^D
-    % cat ctl
-    key dom=bell-labs.com proto=p9sk1 user=gre
-    key proto=apop server=x.y.com user=gre
-    % echo 'delkey proto=apop' &gt;ctl
-    % cat ctl
-    key dom=bell-labs.com proto=p9sk1 user=gre
-    % 
-</pre>(A file with the <TT>l</TT> bit set can be opened by only one process at a time.)<br>
-  <P>
-The heart of the interface is the <TT>rpc</TT> file. Programs authenticate with <TT>factotum</TT> by writing a request to the <TT>rpc</TT> file and reading back the reply; this sequence is called an RPC <EM>transaction</EM>. Requests and replies have the same format: a textual verb possibly followed by arguments, which may be textual or binary. The most common reply verb is <TT>ok</TT>, indicating success. An RPC session begins with a <TT>start</TT> transaction; the argument is a key query as described earlier. Once started, an RPC conversation usually consists of a sequence of <TT>read</TT> and <TT>write</TT> transactions. If the conversation is successful, an <TT>authinfo</TT> transaction will return information about the identities learned during the transaction. The <TT>attr</TT> transaction returns a list of attributes for the current conversation; the list includes any attributes given in the <TT>start</TT> query as well as any public attributes from keys being used.
-  <P>
-As an example of the <TT>rpc</TT> file in action, consider a mail client connecting to a mail server and authenticating using the POP3 protocol's APOP challenge-response command. There are four programs involved: the mail client <EM>PC</EM>, the client <TT>factotum</TT> <EM>FC</EM>, the mail server <EM>PS</EM>, and the server <TT>factotum</TT> <EM>FS</EM>. All authentication computations are handled by the <TT>factotum</TT> processes. The mail programs' role is just to relay messages.
-  <P>
-At startup, the mail server at <TT>x.y.com</TT> begins an APOP conversation with its <TT>factotum</TT> to obtain the banner greeting, which includes a challenge:<br>
-<DL><DT><DD><EM>PS->FS</EM><TT>: start proto=apop role=server<br>
-</TT><EM>FS->PS</EM><TT>: ok<br>
-</TT><EM>PS->FS</EM><TT>: read<br>
-</TT><EM>FS->PS</EM><TT>: ok +OK POP3 </TT><EM>challenge<br>
-</EM></DL>Having obtained the challenge, the server greets the client:<br>
-<DL><DT><DD><EM>PS->PC</EM><TT>: +OK POP3 </TT><EM>challenge<br>
-</EM></DL>The client then uses an APOP conversation with its <TT>factotum</TT> to obtain a response:<br>
-<DL><DT><DD><EM>PC->FC</EM><TT>: start proto=apop role=client server=x.y.com<br>
- </TT><DT><DD><DT><DD><DL><DT><DD></DL><EM>FC->PC</EM><TT>: ok<br>
-</TT><EM>PC->FC</EM><TT>: write +OK POP3 </TT><EM>challenge<br>
-FC->PC</EM><TT>: ok<br>
-</TT><EM>PC->FC</EM><TT>: read<br>
-</TT><EM>FC->PC</EM><TT>: ok APOP gre </TT><EM>response<br>
-</EM></DL><TT>Factotum</TT> requires that <TT>start</TT> requests include a <TT>proto</TT> attribute, and the APOP module requires an additional <TT>role</TT> attribute, but the other attributes are optional and only restrict the key space. Before responding to the <TT>start</TT> transaction, the client <TT>factotum</TT> looks for a key to use for the rest of the conversation. Because of the arguments in the <TT>start</TT> request, the key must have public attributes <TT>proto=apop</TT> and <TT>server=x.y.com</TT>; as mentioned earlier, the APOP module additionally requires that the key have <TT>user</TT> and <TT>!password</TT> attributes. Now that the client has obtained a response from its <TT>factotum</TT>, it echoes that response to the server:
-<DL><DT><DD><EM>PC->PS</EM><TT>: APOP gre </TT><EM>response<br>
-</EM></DL>Similarly, the server passes this message to its <TT>factotum </TT>and obtains another to send back.<br>
-<DL><DT><DD><EM>PS->FS</EM><TT>: write APOP gre </TT><EM>response<br>
-FS->PS</EM><TT>: ok<br>
-</TT><EM>PS->FS</EM><TT>: read<br>
-</TT><EM>FS->PS</EM><TT>: ok +OK welcome<br>
-</TT><EM>PS->PC</EM><TT>: +OK welcome<br>
-</TT></DL>Now the authentication protocol is done, and the server can retrieve information about what the protocol established.<br>
-<DL><DT><DD><EM>PS->FS</EM><TT>: authinfo<br>
-</TT><EM>FS->PS</EM><TT>: ok client=gre <TT>capability=</TT><EM>capability
-</EM><br>
-</TT></DL>The <TT>authinfo</TT> data is a list of <EM>attr</EM><TT>=</TT><EM>value </EM>pairs, here a client user name and a capability. (Protocols that establish shared secrets or provide mutual authentication indicate this by adding appropriate <EM>attr</EM><TT>=</TT><EM>value </EM>pairs.) The capability can be used by the server to change its identity to that of the client, as described earlier. Once it has changed its identity, the server can access and serve the client's mailbox.
-  <P>
-Two more files provide hooks for a graphical <TT>factotum</TT> control interface. The first, <TT>confirm</TT>, allows the user detailed control over the use of certain keys. If a key has a <TT>confirm=</TT> attribute, then the user must approve each use of the key. A separate program with a graphical interface reads from the <TT>confirm</TT> file to see when a confirmation is necessary. The read blocks until a key usage needs to be approved, whereupon it will return a line of the form
-<DL><DT><DD><TT>confirm tag=1</TT> <EM>attributes<br>
-</EM></DL>requesting permission to use the key with those public attributes. The graphical interface then prompts the user for approval and writes back<br>
-<DL><DT><DD><TT>tag=1 answer=yes<br>
-</TT></DL>(or <TT>answer=no</TT>).<br>
-  <P>
-The second file, <TT>needkey</TT>, diverts key requests. In the APOP example, if a suitable key had not been found during the <TT>start</TT> transaction, <TT>factotum</TT> would have indicated failure by returning a response indicating what key was needed:
-<pre>
-    <EM>FC->PC</EM>: needkey proto=apop server=x.y.com user? !password?
-</pre>
-A typical client would then prompt the user for the desired key information, create a new key via the <TT>ctl</TT> file, and then reissue the <TT>start</TT> request. If the <TT>needkey</TT> file is open, then instead of failing, the transaction will block, and the next read from the <TT>/mnt/factotum/needkey</TT> file will return a line of the form
-<DL><DT><DD><TT>needkey tag=1</TT> <EM>attributes<br>
-</EM></DL>The graphical interface then prompts the user for the needed key information, creates the key via the <TT>ctl</TT> file, and writes back <TT>tag=1</TT> to resume the transaction.<br>
-  <P>
-The remaining files are informational and used for debugging. The <TT>proto</TT> file contains a list of supported protocols (to see what protocols the system supports, <TT>cat /mnt/factotum/proto</TT>), and the <TT>log</TT> file contains a log of operations and debugging output enabled by a <TT>debug</TT> control message.
-  <P>
-The next few sections explain how <TT>factotum</TT> is used by system services.<br>
-<H4>3. Authentication in 9P
+<br>&#32;<br>
+External programs manage
+<TT>factotum</TT>'s
+internal key state
+through its file interface,
+writing textual
+<TT>key</TT>
+and
+<TT>delkey</TT>
+commands to the
+<TT>/mnt/factotum/ctl</TT>
+file.
+Both commands take a list of attributes as an argument.
+<TT>Key</TT>
+creates a key with the given attributes, replacing any
+extant key with an identical set of public attributes.
+<TT>Delkey</TT>
+deletes all keys that match the given set of attributes.
+Reading the 
+<TT>ctl</TT>
+file returns a list of keys, one per line, displaying only public attributes.
+The following example illustrates these interactions.
+<DL><DT><DD><TT><PRE>
+% cd /mnt/factotum
+% ls -l
+-lrw------- gre gre 0 Jan 30 22:17 confirm
+--rw------- gre gre 0 Jan 30 22:17 ctl
+-lr-------- gre gre 0 Jan 30 22:17 log
+-lrw------- gre gre 0 Jan 30 22:17 needkey
+--r--r--r-- gre gre 0 Jan 30 22:17 proto
+--rw-rw-rw- gre gre 0 Jan 30 22:17 rpc
+% cat &gt;ctl
+key dom=bell-labs.com proto=p9sk1 user=gre
+    !password='don''t tell'
+key proto=apop server=x.y.com user=gre
+    !password='bite me'
+^D
+% cat ctl
+key dom=bell-labs.com proto=p9sk1 user=gre
+key proto=apop server=x.y.com user=gre
+% echo 'delkey proto=apop' &gt;ctl
+% cat ctl
+key dom=bell-labs.com proto=p9sk1 user=gre
+% 
+</PRE></TT></DL>
+(A file with the
+<TT>l</TT>
+bit set can be opened by only one process at a time.)
+<br>&#32;<br>
+The heart of the interface is the
+<TT>rpc</TT>
+file.
+Programs authenticate with
+<TT>factotum</TT>
+by writing a request to the
+<TT>rpc</TT>
+file
+and reading back the reply; this sequence is called an RPC
+<I>transaction</I>.
+Requests and replies have the same format:
+a textual verb possibly followed by arguments,
+which may be textual or binary.
+The most common reply verb is
+<TT>ok</TT>,
+indicating success.
+An RPC session begins with a
+<TT>start</TT>
+transaction; the argument is a key query as described
+earlier.
+Once started, an RPC conversation usually consists of 
+a sequence of
+<TT>read</TT>
+and
+<TT>write</TT>
+transactions.
+If the conversation is successful, an
+<TT>authinfo</TT>
+transaction will return information about
+the identities learned during the transaction.
+The
+<TT>attr</TT>
+transaction returns a list of attributes for the current
+conversation; the list includes any attributes given in
+the 
+<TT>start</TT>
+query as well as any public attributes from keys being used.
+<br>&#32;<br>
+As an example of the
+<TT>rpc</TT>
+file in action, consider a mail client
+connecting to a mail server and authenticating using
+the POP3 protocol's APOP challenge-response command.
+n(11There are four programs involved: the mail client 11&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99, the client
+<TT>factotum</TT>
+n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99, the mail server 11&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99, and the server
+<TT>factotum</TT>
+n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99.
+All authentication computations are handled by the
+<TT>factotum</TT>
+processes.
+The mail programs' role is just to relay messages.
+<br>&#32;<br>
+At startup, the mail server at
+<TT>x.y.com</TT>
+begins an APOP conversation
+with its
+<TT>factotum</TT>
+to obtain the banner greeting, which
+includes a challenge:
+<DL><DT><DD><TT><PRE>
+n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;F&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99: start proto=apop role=server
+n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99: ok
+n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;F&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99: read
+n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99: ok +OK POP3 &lt;I&gt;challenge&lt;/I&gt;
+</PRE></TT></DL>
+Having obtained the challenge, the server greets the client:
+<DL><DT><DD><TT><PRE>
+n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99: +OK POP3 &lt;I&gt;challenge&lt;/I&gt;
+</PRE></TT></DL>
+The client then uses an APOP conversation with its
+<TT>factotum</TT>
+to obtain a response:
+<DL><DT><DD><TT><PRE>
+n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11-&gt;&lt;I&gt;F&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99: start proto=apop role=client
+            server=x.y.com
+n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99: ok
+n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11-&gt;&lt;I&gt;F&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99: write +OK POP3 &lt;I&gt;challenge&lt;/I&gt;
+n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99: ok
+n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11-&gt;&lt;I&gt;F&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99: read
+n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99: ok APOP gre &lt;I&gt;response&lt;/I&gt;
+</PRE></TT></DL>
+<TT>Factotum</TT>
+requires that
+<TT>start</TT>
+requests include a 
+<TT>proto</TT>
+attribute, and the APOP module requires an additional
+<TT>role</TT>
+attribute, but the other attributes are optional and only
+restrict the key space.
+Before responding to the
+<TT>start</TT>
+transaction, the client
+<TT>factotum</TT>
+looks for a key to
+use for the rest of the conversation.
+Because of the arguments in the
+<TT>start</TT>
+request, the key must have public attributes
+<TT>proto=apop</TT>
+and
+<TT>server=x.y.com</TT>;
+as mentioned earlier,
+the APOP module additionally requires that the key have
+<TT>user</TT>
+and
+<TT>!password</TT>
+attributes.
+Now that the client has obtained a response
+from its
+<TT>factotum</TT>,
+it echoes that response to the server:
+<DL><DT><DD><TT><PRE>
+n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99: APOP gre &lt;I&gt;response&lt;/I&gt;
+</PRE></TT></DL>
+Similarly, the server passes this message to
+its
+<TT>factotum</TT>
+and obtains another to send back.
+<DL><DT><DD><TT><PRE>
+n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;F&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99: write APOP gre &lt;I&gt;response&lt;/I&gt;
+n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99: ok
+n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;F&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99: read
+n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99: ok +OK welcome
+
+n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99: +OK welcome
+</PRE></TT></DL>
+Now the authentication protocol is done, and
+the server can retrieve information
+about what the protocol established.
+<DL><DT><DD><TT><PRE>
+n(1111&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;F&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99: authinfo
+n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99: ok client=gre
+            capability=<I>capability</I>
+</PRE></TT></DL>
+The
+<TT>authinfo</TT>
+data is a list of
+<I>attr</I><TT>=</TT><I>value</I><TT>
+pairs, here a client user name and a capability.
+(Protocols that establish shared secrets or provide
+mutual authentication indicate this by adding
+appropriate
+</TT><I>attr</I><TT>=</TT><I>value</I><TT>
+pairs.)
+The capability can be used by the server to change its
+identity to that of the client, as described earlier.
+Once it has changed its identity, the server can access and serve
+the client's mailbox.
+</TT><br>&#32;<br>
+Two more files provide hooks for a graphical
+<TT>factotum</TT>
+control interface.
+The first, 
+<TT>confirm</TT>,
+allows the user detailed control over the use of certain keys.
+If a key has a
+<TT>confirm=</TT>
+attribute, then the user must approve each use of the key.
+A separate program with a graphical interface reads from the
+<TT>confirm</TT>
+file to see when a confirmation is necessary.
+The read blocks until a key usage needs to be approved, whereupon
+it will return a line of the form
+<DL><DT><DD><TT><PRE>
+confirm tag=1 <I>attributes</I>
+</PRE></TT></DL>
+requesting permission to use the key with those public attributes.
+The graphical interface then prompts the user for approval
+and writes back
+<DL><DT><DD><TT><PRE>
+tag=1 answer=yes
+</PRE></TT></DL>
+(or
+<TT>answer=no</TT>).
+<br>&#32;<br>
+The second file,
+<TT>needkey</TT>,
+diverts key requests.
+In the APOP example, if a suitable key had not been found
+during the
+<TT>start</TT>
+transaction,
+<TT>factotum</TT>
+would have indicated failure by
+returning a response indicating
+what key was needed:
+<DL><DT><DD><TT><PRE>
+n(1111&lt;I&gt;F&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11-&gt;&lt;I&gt;P&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99: needkey proto=apop
+    server=x.y.com user? !password?
+</PRE></TT></DL>
+A typical client would then prompt the user for the desired
+key information, create a new key via the
+<TT>ctl</TT>
+file, and then reissue the 
+<TT>start</TT>
+request.
+If the
+<TT>needkey</TT>
+file is open,
+then instead of failing, the transaction
+will block, and the next read from the
+<TT>/mnt/factotum/needkey</TT>
+file will return a line of the form
+<DL><DT><DD><TT><PRE>
+needkey tag=1 <I>attributes</I><I>
+</PRE></TT></DL>
+The graphical interface then prompts the user for the needed
+key information, creates the key via the
+</I><TT>ctl</TT><I>
+file, and writes back
+</I><TT>tag=1</TT><I>
+to resume the transaction.
+</I><br>&#32;<br>
+The remaining files are informational and used for debugging.
+The
+<TT>proto</TT>
+file contains a list of supported protocols (to see what protocols the
+system supports,
+<TT>cat</TT>
+<TT>/mnt/factotum/proto</TT>),
+and the
+<TT>log</TT>
+file contains a log of operations and debugging output
+enabled by a
+<TT>debug</TT>
+control message.
+<br>&#32;<br>
+The next few sections explain how
+<TT>factotum</TT>
+is used by system services.
+<H4>3 Authentication in 9P
 </H4>
-Plan 9 uses a remote file access protocol, 9P [Pike93], to connect to resources such as the file server and remote processes. The original design for 9P included special messages at the start of a conversation to authenticate the user. Multiple users can share a single connection, such as when a CPU server runs processes for many users connected to a single file server, but each must authenticate separately. The authentication protocol, similar to that of Kerberos [Stei88], used a sequence of messages passed between client, file server, and authentication server to verify the identities of the user, calling machine, and serving machine. One major drawback to the design was that the authentication method was defined by 9P itself and could not be changed. Moreover, there was no mechanism to relegate authentication to an external (trusted) agent, so a process implementing 9P needed, besides support for file service, a substantial body of cryptographic code to implement a handful of startup messages in the protocol.
-  <P>
-A recent redesign of 9P addressed a number of file service issues outside the scope of this paper. On issues of authentication, there were two goals: first, to remove details about authentication from the protocol itself; second, to allow an external program to execute the authentication part of the protocol. In particular, we wanted a way to quickly incorporate ideas found in other systems such as SFS [Mazi99].
-  <P>
-Since 9P is a file service protocol, the solution involved creating a new type of file to be served: an <EM>authentication file</EM>. Connections to a 9P service begin in a state that
+<br>&#32;<br>
+Plan 9 uses a remote file access protocol, 9P
+[Pike93],
+to connect to resources such as the
+file server and remote processes.
+The original design for 9P included special messages at the start of a conversation
+to authenticate the user.
+Multiple users can share a single connection, such as when a CPU server
+runs processes for many users connected to a single file server,
+but each must authenticate separately.
+The authentication protocol, similar to that of Kerberos
+[Stei88],
+used a sequence of messages passed between client, file server, and authentication
+server to verify the identities of the user, calling machine, and serving machine.
+One major drawback to the design was that the authentication method was defined by 9P
+itself and could not be changed.  
+Moreover, there was no mechanism to relegate
+authentication to an external (trusted) agent,
+so a process implementing 9P needed, besides support for file service,
+a substantial body of cryptographic code to implement a handful of startup messages
+in the protocol.
+<br>&#32;<br>
+A recent redesign of 9P
+addressed a number of file service issues outside the scope of this paper.
+On issues of authentication, there were two goals:
+first, to remove details about authentication from the
+protocol itself; second, to allow an external program to execute the authentication
+part of the protocol.
+In particular, we wanted a way to quickly incorporate
+ideas found in other systems such as SFS
+[Mazi99].
+<br>&#32;<br>
+Since 9P is a file service protocol, the solution involved creating a new type of file
+to be served: an
+<I>authentication</I>
+<I>file</I>.
+Connections to a 9P service begin in a state that
 allows no general file access but permits the client
-to open an authentication file by sending a special message, generated by the new <TT>fauth </TT>system call:
-<DL><DT><DD><TT>afd = fauth(int fd, char *servicename);<br>
-</TT></DL>Here <TT>fd</TT> is the user's file descriptor for the established network connection to the 9P server and <TT>servicename</TT> is the name of the desired service offered on that server, typically the file subsystem to be accessed. The returned file descriptor, <TT>afd</TT>, is a unique handle representing the authentication file created for this connection to authenticate to this service; it is analogous to a capability. The authentication file represented by <TT>afd</TT> is not otherwise addressable on the server, such as through the file name hierarchy. In all other respects, it behaves like a regular file; most important, it accepts standard read and write operations.
-  <P>
-To prove its identity, the user process (via <TT>factotum</TT>) executes the authentication protocol, described in the next section of this paper, over the <TT>afd</TT> file descriptor with ordinary reads and writes. When client and server have successfully negotiated, the authentication file changes state so it can be used as evidence of authority in <TT>mount</TT>.
-  <P>
-Once identity is established, the process presents the (now verified) <TT>afd</TT> as proof of identity to the <TT>mount</TT> system call:
-<pre>
-    mount(int fd, int afd, char *mountpoint,
-        int flag, char *servicename)
-</pre>
-succeeds, the user now has appropriate permissions for the file hierarchy made visible at the mount point.<br>
-  <P>
-This sequence of events has several advantages. First, the actual authentication protocol is implemented using regular reads and writes, not special 9P messages, so they can be processed, forwarded, proxied, and so on by any 9P agent without special arrangement. Second, the business of negotiating the authentication by reading and writing the authentication file can be delegated to an outside agent, in particular <TT>factotum</TT>; the programs that implement the client and server ends of a 9P conversation need no authentication or cryptographic code. Third, since the authentication protocol is not defined by 9P itself, it is easy to change and can even be negotiated dynamically. Finally, since <TT>afd</TT> acts like a capability, it can be treated like one: handed to another process to give it special permissions; kept around for later use when authentication is again required; or closed to make sure no other process can use it.
-  <P>
-All these advantages stem from moving the authentication negotiation into reads and writes on a separate file. As is often the case in Plan 9, making a resource (here authentication) accessible with a file-like interface reduces <EM>a priori </EM>the need for special interfaces.<br>
-  <P>
-<H4>3.1. Plan 9 shared key protocol
+to open an authentication file
+by sending a special message, generated by the new
+<TT>fauth</TT>
+system call:
+<DL><DT><DD><TT><PRE>
+afd = fauth(int fd, char *servicename);
+</PRE></TT></DL>
+Here
+<TT>fd</TT>
+is the user's file descriptor for the established network connection to the 9P server
+and
+<TT>servicename</TT>
+is the name of the desired service offered on that server, typically the file subsystem
+to be accessed.
+The returned file descriptor,
+<TT>afd</TT>,
+is a unique handle representing the authentication file
+created for this connection to authenticate to
+this service; it is analogous to a capability.
+The authentication file represented by
+<TT>afd</TT>
+is not otherwise addressable on the server, such as through
+the file name hierarchy.
+In all other respects, it behaves like a regular file;
+most important, it accepts standard read and write operations.
+<br>&#32;<br>
+To prove its identity, the user process (via
+<TT>factotum</TT>)
+executes the authentication protocol,
+described in the next section of this paper,
+over the
+<TT>afd</TT>
+file descriptor with ordinary reads and writes.
+When client and server have successfully negotiated, the authentication file
+changes state so it can be used as evidence of authority in
+<TT>mount</TT>.
+<br>&#32;<br>
+Once identity is established, the process presents the (now verified)
+<TT>afd</TT>
+as proof of identity to the
+<TT>mount</TT>
+system call:
+<DL><DT><DD><TT><PRE>
+mount(int fd, int afd, char *mountpoint,
+      int flag, char *servicename)
+</PRE></TT></DL>
+If the
+<TT>mount</TT>
+succeeds, the user now
+has appropriate permissions for the file hierarchy made
+visible at the mount point.
+<br>&#32;<br>
+This sequence of events has several advantages.
+First, the actual authentication protocol is implemented using regular reads and writes,
+not special 9P messages, so
+they can be processed, forwarded, proxied, and so on by
+any 9P agent without special arrangement.
+Second, the business of negotiating the authentication by reading and writing the
+authentication file can be delegated to an outside agent, in particular
+<TT>factotum</TT>;
+the programs that implement the client and server ends of a 9P conversation need
+no authentication or cryptographic code.
+Third,
+since the authentication protocol is not defined by 9P itself, it is easy to change and
+can even be negotiated dynamically.
+Finally, since
+<TT>afd</TT>
+acts like a capability, it can be treated like one:
+handed to another process to give it special permissions;
+kept around for later use when authentication is again required;
+or closed to make sure no other process can use it.
+<br>&#32;<br>
+All these advantages stem from moving the authentication negotiation into
+reads and writes on a separate file.
+As is often the case in Plan 9,
+making a resource (here authentication) accessible with a file-like interface
+reduces
+<I>a</I>
+<I>priori</I>
+the need for special interfaces.
+<br>&#32;<br>
+<H4>3.1 Plan 9 shared key protocol
 </H4>
-In addition to the various standard protocols supported by <TT>factotum</TT>, we use a shared key protocol for native Plan 9 authentication. This protocol provides backward compatibility with older versions of the system. One reason for the new architecture is to let us replace such protocols in the near future with more cryptographically secure ones.
-  <P>
-<EM>P9sk1</EM> is a shared key protocol that uses tickets much like those in the original Kerberos. The difference is that we've replaced the expiration time in Kerberos tickets with a random nonce parameter and a counter. We summarize it here:
-<pre>
-    <EM>C->S</EM>:      <EM>nonceC</EM>
-    <EM>S->C</EM>:      <EM>nonceS</EM>,<EM>uidS</EM>,<EM>domainS</EM>
+<br>&#32;<br>
+In addition to the various standard protocols supported by
+<TT>factotum</TT>,
+we use a shared key protocol for native
+Plan 9 authentication.
+This protocol provides backward compatibility with
+older versions of the system.  One reason for the new
+architecture is to let us replace such protocols
+in the near future with more cryptographically secure ones.
+<br>&#32;<br>
+<I>P9sk1</I>
+is a shared key protocol that uses tickets much like those
+in the original Kerberos.
+The difference is that we've
+replaced the expiration time in Kerberos tickets with
+a random nonce parameter and a counter.
+We summarize it here:
+<DL><DT><DD><TT><PRE>
+n(1111&lt;I&gt;C&lt;/I&gt;-&gt;&lt;I&gt;S&lt;/I&gt;:  &lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99
+n(1111&lt;I&gt;S&lt;/I&gt;-&gt;&lt;I&gt;C&lt;/I&gt;:  &lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;domain&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99
 
-    <EM>C->A</EM>:      <EM>nonceS</EM>,<EM>uidS</EM>,<EM>domainS</EM>,<EM>uidC</EM>,<EM>factotumC</EM>
-    <EM>A->C</EM>:      <EM>KC</EM>{<EM>nonceS</EM>,<EM>uidC</EM>,<EM>uidS</EM>,<EM>Kn</EM>},
-                 <EM>KS</EM>{<EM>nonceS</EM>,<EM>uidC</EM>,<EM>uidS</EM>,<EM>Kn</EM>}
+n(1111&lt;I&gt;C&lt;/I&gt;-&gt;&lt;I&gt;A&lt;/I&gt;:  &lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;domain&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11,n(99
+n(11         11&lt;I&gt;factotum&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99
+n(1111&lt;I&gt;A&lt;/I&gt;-&gt;&lt;I&gt;C&lt;/I&gt;:  &lt;I&gt;K&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11{&lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;,11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11},n(99
+n(11         11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11{&lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;,11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11}n(99
 
-    <EM>C->S</EM>:      <EM>KS</EM>{<EM>nonceS</EM>,<EM>uidC</EM>,<EM>uidS</EM>,<EM>Kn</EM>},
-                 <EM>Kn</EM>{<EM>nonceS</EM>,<EM>counter</EM>}
-    <EM>S->C</EM>:      <EM>Kn</EM>{<EM>nonceC</EM>,<EM>counter</EM>}
-</pre>
-(Here <EM>K</EM>{<EM>x</EM>} indicates <EM>x </EM>encrypted with DES key <EM>K</EM>.) The first two messages exchange nonces and server identification. After this initial exchange, the client contacts the authentication server to obtain a pair of encrypted tickets, one encrypted with the client key and one with the server key. The client relays the server ticket to the server. The server believes that the ticket is new because it contains <EM>nonceS </EM>and that the ticket is from the authentication server because it is encrypted in the server key <EM>KS</EM>. The ticket is basically a statement from the authentication server that now <EM>uidC </EM>and <EM>uidS </EM>share a secret <EM>Kn</EM>. The authenticator <EM>Kn</EM>{<EM>nonceS</EM>,<EM>counter</EM>} convinces the server that the client knows <EM>Kn </EM>and thus must be <EM>uidC</EM>. Similarly, authenticator <EM>Kn</EM>{<EM>nonceC</EM>,<EM>counter</EM>} convinces the client that the server knows <EM>Kn </EM>and thus must be <EM>uidS</EM>. Tickets can be reused, without contacting the authentication server again, by incrementing the counter before each authenticator is generated.
-  <P>
-In the future we hope to introduce a public key version of p9sk1, which would allow authentication even when the authentication server is not available.<br>
-<H4>3.2. The authentication server
+n(1111&lt;I&gt;C&lt;/I&gt;-&gt;&lt;I&gt;S&lt;/I&gt;:  &lt;I&gt;K&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11{&lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11},n(99
+n(11         11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11{&lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;counter&lt;/I&gt;}n(99
+n(1111&lt;I&gt;S&lt;/I&gt;-&gt;&lt;I&gt;C&lt;/I&gt;:  &lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11{&lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11,&lt;I&gt;counter&lt;/I&gt;}n(99
+</PRE></TT></DL>
+n(11(Here 11&lt;I&gt;K&lt;/I&gt;{&lt;I&gt;x&lt;/I&gt;}n(99 indicates 11&lt;I&gt;x&lt;/I&gt;n(99 encrypted with
+n(11DES key 11&lt;I&gt;K&lt;/I&gt;n(99.)
+The first two messages exchange nonces and server identification.
+After this initial exchange, the client contacts the authentication
+server to obtain a pair of encrypted tickets, one encrypted with
+the client key and one with the server key.
+The client relays the server ticket to the server.
+The server believes that the ticket is new
+because it contains
+n(1111&lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99
+and that the ticket is from the authentication
+n(11server because it is encrypted in the server key 11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99.
+The ticket is basically a statement from the authentication
+n(11server that now 11&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99 and 11&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99 share a
+n(11secret 11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11n(99.
+n(11The authenticator 11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11{&lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;counter&lt;/I&gt;}n(99
+n(11convinces the server that the client knows 11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11n(99 and thus
+n(11must be 11&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99.
+n(11Similarly, authenticator 11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11{&lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11,&lt;I&gt;counter&lt;/I&gt;}n(99
+n(11convinces the client that the server knows 11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11n(99 and thus
+n(11must be 11&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99.
+Tickets can be reused, without contacting the authentication
+server again, by incrementing the counter before each
+authenticator is generated.
+<br>&#32;<br>
+In the future we hope to introduce a public key version of
+p9sk1,
+which would allow authentication even
+when the authentication server is not available.
+<H4>3.2 The authentication server
 </H4>
-Each Plan 9 security domain has an authentication server (AS) that all users trust to keep the complete set of shared keys. It also offers services for users and administrators to manage the keys, create and disable accounts, and so on. It typically runs on a standalone machine with few other services. The AS comprises two services, <TT>keyfs</TT> and <TT>authsrv</TT>.
-  <P>
-<TT>Keyfs</TT> is a user-level file system that manages an encrypted database of user accounts. Each account is represented by a directory containing the files <TT>key</TT>, containing the Plan 9 key for p9sk1; <TT>secret</TT> for the challenge/response protocols (APOP, VNC, CHAP, MSCHAP, CRAM); <TT>log</TT> for authentication outcomes; <TT>expire</TT> for an expiration time; and <TT>status</TT>. If the expiration time passes, if the number of successive failed authentications exceeds 50, or if <TT>disabled</TT> is written to the status file, any attempt to access the <TT>key</TT> or <TT>secret</TT> files will fail.
-  <P>
-<TT>Authsrv</TT> is a network service that brokers shared key authentications for the protocols p9sk1, APOP, VNC, CHAP, MSCHAP, and CRAM. Remote users can also call <TT>authsrv</TT> to change their passwords.<br>
-  <P>
-The p9sk1 protocol was described in the previous section. The challenge/response protocols differ in detail but all follow the general structure:
-<pre>
-    <EM>C->S</EM>:      <EM>nonceC</EM>
-    <EM>S->C</EM>:      <EM>nonceS</EM>,<EM>uidS</EM>,<EM>domainS</EM>
-    <EM>C->A</EM>:      <EM>nonceS</EM>,<EM>uidS</EM>,<EM>domainS</EM>, <EM>hostidC</EM>,<EM>uidC</EM>
-    <EM>A->C</EM>:      <EM>KC</EM>{<EM>nonceS</EM>,<EM>uidC</EM>,<EM>uidS</EM>,<EM>Kn</EM>},
-                  <EM>KS</EM>{<EM>nonceS</EM>,<EM>uidC</EM>,<EM>uidS</EM>,<EM>Kn</EM>}
-    <EM>C->S</EM>:      <EM>KS</EM>{<EM>nonceS</EM>,<EM>uidC</EM>,<EM>uidS</EM>,<EM>Kn</EM>}, <EM>Kn</EM>{<EM>nonceS</EM>}
-    <EM>S->C</EM>:      <EM>Kn</EM>{<EM>nonceC</EM>}
-</pre>
+<br>&#32;<br>
+Each Plan 9 security domain has an authentication server (AS)
+that all users trust to keep the complete set of shared keys.
+It also offers services for users and administrators to manage the
+keys, create and disable accounts, and so on.
+It typically runs on
+a standalone machine with few other services.
+The AS comprises two services,
+<TT>keyfs</TT>
+and
+<TT>authsrv</TT>.
+<br>&#32;<br>
+<TT>Keyfs</TT>
+is a user-level file system that manages an
+encrypted database of user accounts.
+Each account is represented by a directory containing the
+files
+<TT>key</TT>,
+containing the Plan 9 key for p9sk1;
+<TT>secret</TT>
+for the challenge/response protocols (APOP, VNC, CHAP, MSCHAP,
+CRAM);
+<TT>log</TT>
+for authentication outcomes;
+<TT>expire</TT>
+for an expiration time; and
+<TT>status</TT>.
+If the expiration time passes,
+if the number of successive failed authentications
+exceeds 50, or if
+<TT>disabled</TT>
+is written to the status file,
+any attempt to access the
+<TT>key</TT>
+or
+<TT>secret</TT>
+files will fail.
+<br>&#32;<br>
+<TT>Authsrv</TT>
+is a network service that brokers shared key authentications
+for the protocols p9sk1, APOP, VNC, CHAP, MSCHAP,
+and CRAM.  Remote users can also call
+<TT>authsrv</TT>
+to change their passwords.
+<br>&#32;<br>
+The
+p9sk1
+protocol was described in the previous
+section.
+The challenge/response protocols differ
+in detail but all follow the general structure:
+<DL><DT><DD><TT><PRE>
+n(1111&lt;I&gt;C&lt;/I&gt;-&gt;&lt;I&gt;S&lt;/I&gt;:  &lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99
+n(1111&lt;I&gt;S&lt;/I&gt;-&gt;&lt;I&gt;C&lt;/I&gt;:  &lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;domain&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11n(99
+n(1111&lt;I&gt;C&lt;/I&gt;-&gt;&lt;I&gt;A&lt;/I&gt;:  &lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;domain&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,n(99
+n(11         11&lt;I&gt;hostid&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99
+n(1111&lt;I&gt;A&lt;/I&gt;-&gt;&lt;I&gt;C&lt;/I&gt;:  &lt;I&gt;K&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11{&lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;,11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11},n(99
+n(11         11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11{&lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;,11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11}n(99
+n(1111&lt;I&gt;C&lt;/I&gt;-&gt;&lt;I&gt;S&lt;/I&gt;:  &lt;I&gt;K&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11{&lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11,&lt;I&gt;uid&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;,11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11},n(99
+n(11         11&lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11{&lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;S&lt;/I&gt;11}n(99
+n(1111&lt;I&gt;S&lt;/I&gt;-&gt;&lt;I&gt;C&lt;/I&gt;:  &lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11{&lt;I&gt;nonce&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11}n(99
+</PRE></TT></DL>
 The password protocol is:
-<pre>
-    <EM>C->A</EM>:      <EM>uidC</EM>
-    <EM>A->C</EM>:      <EM>Kc</EM>{<EM>Kn</EM>}
-    <EM>C->A</EM>:      <EM>Kn</EM>{<EM>passwordold</EM>,<EM>passwordnew</EM>}
-    <EM>A->C</EM>:      <EM>OK</EM>
-</pre>To avoid replay attacks, the pre-encryption clear text for each of the protocols (as well as for p9sk1) includes a tag indicating the encryption's role in the protocol. We elided them in these outlines.<br>
-<H4>3.3. Protocol negotiation
-</H4> 
-Rather than require particular protocols for particular services, we implemented a negotiation metaprotocol, <EM>p9any</EM>, which chooses the actual authentication protocol to use. P9any is used now by all native services on Plan 9.<br>
-  <P>
-The metaprotocol is simple. The callee sends a null-terminated string of the form:<br>
-<DL><DT><DD><TT>v</TT><EM>n proto</EM>1<TT>@</TT><EM>domain</EM>1 <EM>proto</EM>2<TT>@</TT><EM>domain</EM>2 <TT>...<br>
-</TT></DL>where <EM>n </EM>is a decimal version number, <EM>protok </EM>is the name of a protocol for which the <TT>factotum</TT> has a key, and <EM>domaink </EM>is the name of the domain in which the key is valid. The caller then responds<br>
-<DL><DT><DD><EM>proto</EM><TT>@</TT><EM>domain<br>
-</EM></DL>indicating its choice. Finally the callee responds<br>
-<DL><DT><DD><TT>OK<br>
-</TT></DL>Any other string indicates failure. At this point the chosen protocol commences. The final fixed-length reply is used to make it easy to delimit the I/O stream should the chosen protocol require the caller rather than the callee to send the first message.<br>
-  <P>
-With this negotiation metaprotocol, the underlying authentication protocols used for Plan 9 services can be changed under any application just by changing the keys known by the <TT>factotum</TT> agents at each end.<br>
-  <P>
-P9any is vulnerable to man in the middle attacks to the extent that the attacker may constrain the possible choices by changing the stream. However, we believe this is acceptable since the attacker cannot force either side to choose algorithms that it is unwilling to use.
-<H4>4. Library Interface to Factotum
-</H4> 
-Although programs can access <TT>factotum</TT>'s services through its file system interface, it is more common to use a C library that packages the interaction. There are a number of routines in the library, not all of which are relevant here, but a few examples should give their flavor.
-  <P>
-First, consider the problem of mounting a remote file server using 9P. An earlier discussion showed how the <TT>fauth</TT> and <TT>mount</TT> system calls use an authentication file, <TT>afd</TT>, as a capability, but not how <TT>factotum</TT> manages <TT>afd</TT>. The library contains a routine, <TT>amount</TT> (authenticated mount), that is used by most programs in preference to the raw <TT>fauth</TT> and <TT>mount</TT> calls. <TT>Amount</TT> engages <TT>factotum</TT> to validate <TT>afd</TT>; here is the complete code:
-<pre>
-    int
-    amount(int fd, char *mntpt, int flags, char *aname)
-    {
-        int afd, ret;
-        AuthInfo *ai;
-        afd = fauth(fd, aname);
-        if(afd &gt;= 0){
-             ai = auth_proxy(afd, amount_getkey,
-              &quot;proto=p9any role=client&quot;);
-            if(ai != NULL)
-              auth_freeAI(ai);
-        }
-        ret = mount(fd, afd, mntpt,flags, aname);
-        if(afd &gt;= 0)
-            close(afd);
-        return ret;
-    }
-</pre>
-where parameter <TT>fd</TT> is a file descriptor returned by <TT>open</TT> or <TT>dial</TT> for a new connection to a file server. The conversation with <TT>factotum</TT> occurs in the call to <TT>auth_proxy</TT>, which specifies, as a key query, which authentication protocol to use (here the metaprotocol <TT>p9any</TT>) and the role being played (<TT>client</TT>). <TT>Auth_proxy</TT> will read and write the <TT>factotum</TT> files, and the authentication file descriptor <TT>afd</TT>, to validate the user's right to access the service. If the call is successful, any auxiliary data, held in an <TT>AuthInfo</TT> structure, is freed. In any case, the <TT>mount</TT> is then called with the (perhaps validated) <TT>afd.</TT> A 9P server can cause the <TT>fauth</TT> system call to fail, as an indication that authentication is not required to access the service.
-  <P>
-The second argument to <TT>auth_proxy</TT> is a function, here <TT>amount_getkey</TT>, to be called if secret information such as a password or response to a challenge is required as part of the authentication. This function, of course, will provide this data to <TT>factotum</TT> as a <TT>key</TT> message on the <TT>/mnt/factotum/ctl</TT> file.
-  <P>
-Although the final argument to <TT>auth_proxy</TT> in this example is a simple string, in general it can be a formatted-print specifier in the manner of <TT>printf</TT>, to enable the construction of more elaborate key queries.<br>
-  <P>
-As another example, consider the Plan 9 <TT>cpu</TT> service, which exports local devices to a shell process on a remote machine, typically to connect the local screen and keyboard to a more powerful computer. At heart, <TT>cpu</TT> is a superset of a service called <TT>exportfs</TT> [Pike93], which allows one machine to see an arbitrary portion of the file name space of another machine, such as to export the network device to another machine for gatewaying. However, <TT>cpu</TT> is not just <TT>exportfs</TT> because it also delivers signals such as interrupt and negotiates the initial environment for the remote shell.
-  <P>
-To authenticate an instance of <TT>cpu</TT> requires <TT>factotum</TT> processes on both ends: the local, client end running as the user on a terminal and the remote, server end running as the host owner of the server machine. Here is schematic code for the two ends:
-<pre>
-    /* client */
-    int
-    p9auth(int fd)
-    {
-        AuthInfo *ai;
-        ai = auth_proxy(fd, auth_getkey, &quot;proto=p9any role=client&quot;);
-        if(ai == NULL)
-            return -1;
-        /* start cpu protocol here */
-    }
-    /* server */
-    int
-    srvp9auth(int fd, char *user)
-    {
-        AuthInfo *ai;
-        ai = auth_proxy(fd, NULL, &quot;proto=p9any role=server&quot;);
-        if(ai == NULL)
-            return -1;
-        /* set user id for server process */
-        if(auth_chuid(ai, NULL) &lt; 0)
-            return -1;
-        /* start cpu protocol here */
-    }
-</pre>
-Auth_chuid</TT> encapsulates the negotiation to change a user id using the <TT>caphash</TT> and <TT>capuse</TT> files of the (server) kernel. Note that although the client process may ask the user for new keys, using <TT>auth_getkey</TT>, the server machine, presumably a shared machine with a pseudo-user for the host owner, sets the key-getting function to <TT>NULL</TT>.
-<H4>5. Secure Store
+<DL><DT><DD><TT><PRE>
+n(1111&lt;I&gt;C&lt;/I&gt;-&gt;&lt;I&gt;A&lt;/I&gt;:  &lt;I&gt;uid&lt;/I&gt;&lt;I&gt;C&lt;/I&gt;11n(99
+n(1111&lt;I&gt;A&lt;/I&gt;-&gt;&lt;I&gt;C&lt;/I&gt;:  &lt;I&gt;K&lt;/I&gt;&lt;I&gt;c&lt;/I&gt;11{&lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11}n(99
+n(1111&lt;I&gt;C&lt;/I&gt;-&gt;&lt;I&gt;A&lt;/I&gt;:  &lt;I&gt;K&lt;/I&gt;&lt;I&gt;n&lt;/I&gt;11{&lt;I&gt;password&lt;/I&gt;&lt;I&gt;old&lt;/I&gt;11,&lt;I&gt;password&lt;/I&gt;&lt;I&gt;new&lt;/I&gt;11}n(99
+n(1111&lt;I&gt;A&lt;/I&gt;-&gt;&lt;I&gt;C&lt;/I&gt;:  &lt;I&gt;OK&lt;/I&gt;n(99
+</PRE></TT></DL>
+To avoid replay attacks, the pre-encryption
+clear text for each of the protocols (as well as for p9sk1) includes
+a tag indicating the encryption's role in the
+protocol.  We elided them in these outlines.
+<H4>3.3 Protocol negotiation
+</H4>
+<br>&#32;<br>
+Rather than require particular protocols for particular services,
+we implemented a negotiation metaprotocol,
+<I>p9any</I>,
+which chooses the actual authentication protocol to use.
+P9any
+is used now by all native services on Plan 9.
+<br>&#32;<br>
+The metaprotocol is simple.  The callee sends a
+null-terminated string of the form:
+<DL><DT><DD><TT><PRE>
+n(11v.11&lt;I&gt;n&lt;/I&gt;n(99 11&lt;I&gt;proto&lt;/I&gt;111n(99@11&lt;I&gt;domain&lt;/I&gt;111n(99 11&lt;I&gt;proto&lt;/I&gt;211n(99@11&lt;I&gt;domain&lt;/I&gt;211n(99 ...
+</PRE></TT></DL>
+where
+<I>n</I>
+n(11is a decimal version number, 11&lt;I&gt;proto&lt;/I&gt;&lt;I&gt;k&lt;/I&gt;11n(99
+is the name of a protocol for which the
+<TT>factotum</TT>
+n(11has a key, and 11&lt;I&gt;domain&lt;/I&gt;&lt;I&gt;k&lt;/I&gt;11n(99
+is the name of the domain in which the key is
+valid.
+The caller then responds
+<DL><DT><DD><TT><PRE>
+<I>proto</I>@<I>domain</I>
+</PRE></TT></DL>
+indicating its choice.
+Finally the callee responds
+<DL><DT><DD><TT><PRE>
+OK
+</PRE></TT></DL>
+Any other string indicates failure.
+At this point the chosen protocol commences.
+The final fixed-length reply is used to make it easy to
+delimit the I/O stream should the chosen protocol
+require the caller rather than the callee to send the first message.
+<br>&#32;<br>
+With this negotiation metaprotocol, the underlying
+authentication protocols used for Plan 9 services
+can be changed under any application just
+by changing the keys known by the
+<TT>factotum</TT>
+agents at each end.
+<br>&#32;<br>
+P9any is vulnerable to man in the middle attacks
+to the extent that the attacker may constrain the
+possible choices by changing the stream.  However,
+we believe this is acceptable since the attacker
+cannot force either side to choose algorithms
+that it is unwilling to use.
+<H4>4 Library Interface to Factotum
+</H4>
+<br>&#32;<br>
+Although programs can access
+<TT>factotum</TT>'s
+services through its file system interface,
+it is more common to use a C library that
+packages the interaction.
+There are a number of routines in the library,
+not all of which are relevant here, but a few
+examples should give their flavor.
+<br>&#32;<br>
+First, consider the problem of mounting a remote file server using 9P.
+An earlier discussion showed how the
+<TT>fauth</TT>
+and
+<TT>mount</TT>
+system calls use an authentication file,
+<TT>afd</TT>,
+as a capability,
+but not how
+<TT>factotum</TT>
+manages
+<TT>afd</TT>.
+The library contains a routine,
+<TT>amount</TT>
+(authenticated mount), that is used by most programs in preference to
+the raw
+<TT>fauth</TT>
+and
+<TT>mount</TT>
+calls.
+<TT>Amount</TT>
+engages
+<TT>factotum</TT>
+to validate
+<TT>afd</TT>;
+here is the complete code:
+<DL><DT><DD><TT><PRE>
+int
+amount(int fd, char *mntpt,
+	int flags, char *aname)
+{
+	int afd, ret;
+	AuthInfo *ai;
+
+	afd = fauth(fd, aname);
+	if(afd &gt;= 0){
+		ai = auth_proxy(afd, amount_getkey,
+			"proto=p9any role=client");
+		if(ai != NULL)
+			auth_freeAI(ai);
+	}
+	ret = mount(fd, afd, mntpt,
+		flags, aname);
+	if(afd &gt;= 0)
+		close(afd);
+	return ret;
+}
+</PRE></TT></DL>
+where parameter
+<TT>fd</TT>
+is a file descriptor returned by
+<TT>open</TT>
+or
+<TT>dial</TT>
+for a new connection to a file server.
+The conversation with
+<TT>factotum</TT>
+occurs in the call to
+<TT>auth_proxy</TT>,
+which specifies, as a key query,
+which authentication protocol to use
+(here the metaprotocol
+<TT>p9any</TT>)
+and the role being played
+(<TT>client</TT>).
+<TT>Auth_proxy</TT>
+will read and write the
+<TT>factotum</TT>
+files, and the authentication file descriptor
+<TT>afd</TT>,
+to validate the user's right to access the service.
+If the call is successful, any auxiliary data, held in an
+<TT>AuthInfo</TT>
+structure, is freed.
+In any case, the
+<TT>mount</TT>
+is then called with the (perhaps validated)
+<TT>afd.</TT>
+A 9P server can cause the
+<TT>fauth</TT>
+system call to fail, as an indication that authentication is
+not required to access the service.
+<br>&#32;<br>
+The second argument to
+<TT>auth_proxy</TT>
+is a function, here
+<TT>amount_getkey</TT>,
+to be called if secret information such as a password or
+response to a challenge is required as part of the authentication.
+This function, of course, will provide this data to
+<TT>factotum</TT>
+as a
+<TT>key</TT>
+message on the
+<TT>/mnt/factotum/ctl</TT>
+file.
+<br>&#32;<br>
+Although the final argument to
+<TT>auth_proxy</TT>
+in this example is a simple string, in general
+it can be a formatted-print specifier in the manner of
+<TT>printf</TT>,
+to enable the construction of more elaborate key queries.
+<br>&#32;<br>
+As another example, consider the Plan 9
+<TT>cpu</TT>
+service, which exports local devices to a shell process on
+a remote machine, typically
+to connect the local screen and keyboard to a more powerful computer.
+At heart,
+<TT>cpu</TT>
+is a superset of a service called
+<TT>exportfs</TT>
+[Pike93],
+which allows one machine to see an arbitrary portion of the file name space
+of another machine, such as to
+export the network device to another machine
+for gatewaying.
+However,
+<TT>cpu</TT>
+is not just
+<TT>exportfs</TT>
+because it also delivers signals such as interrupt
+and negotiates the initial environment
+for the remote shell.
+<br>&#32;<br>
+To authenticate an instance of
+<TT>cpu</TT>
+requires
+<TT>factotum</TT>
+processes on both ends: the local, client
+end running as the user on a terminal
+and the remote, server
+end running as the host owner of the server machine.
+Here is schematic code for the two ends:
+<DL><DT><DD><TT><PRE>
+/* client */
+int
+p9auth(int fd)
+{
+	AuthInfo *ai;
+
+	ai = auth_proxy(fd, auth_getkey,
+		"proto=p9any role=client");
+	if(ai == NULL)
+		return -1;
+
+	/* start cpu protocol here */
+}
+
+/* server */
+int
+srvp9auth(int fd, char *user)
+{
+	AuthInfo *ai;
+
+	ai = auth_proxy(fd, NULL,
+		"proto=p9any role=server");
+	if(ai == NULL)
+		return -1;
+	/* set user id for server process */
+	if(auth_chuid(ai, NULL) &lt; 0)
+		return -1;
+
+	/* start cpu protocol here */
+}
+</PRE></TT></DL>
+<TT>Auth_chuid</TT>
+encapsulates the negotiation to change a user id using the
+<TT>caphash</TT>
+and
+<TT>capuse</TT>
+files of the (server) kernel.
+Note that although the client process may ask the user for new keys, using
+<TT>auth_getkey</TT>,
+the server machine, presumably a shared machine with a pseudo-user for
+the host owner, sets the key-getting function to
+<TT>NULL</TT>.
+<H4>5 Secure Store
 </H4>
-<TT>Factotum</TT> keeps its keys in volatile memory, which must somehow be
+<br>&#32;<br>
+<TT>Factotum</TT>
+keeps its keys in volatile memory, which must somehow be
 initialized at boot time.
 Therefore,
-<TT>factotum</TT> must be supplemented by a persistent store, perhaps a floppy disk containing a key file of commands to be copied into <TT>/mnt/factotum/ctl</TT> during bootstrap. But removable media are a nuisance to carry and are vulnerable to theft. Keys could be stored encrypted on a shared file system, but only if those keys are not necessary for authenticating to the file system in the first place. Even if the keys are encrypted under a user password, a thief might well succeed with a dictionary attack. Other risks of local storage are loss of the contents through mechanical mishap or dead batteries. Thus for convenience and safety we provide a <TT>secstore</TT> (secure store) server in the network to hold each user's permanent list of keys, a <EM>key file</EM>.
-  <P>
-<TT>Secstore</TT> is a file server for encrypted data, used only during bootstrapping. It must provide strong authentication and resistance to passive and active protocol attacks while assuming nothing more from the client than a password. Once <TT>factotum</TT> has loaded the key file, further encrypted or authenticated file storage can be accomplished by standard mechanisms.
-  <P>
-The cryptographic technology that enables <TT>secstore</TT> is a form of encrypted key exchange called PAK [Boyk00], analogous to EKE [Bell93], SRP [Wu98], or SPEKE [Jabl]. PAK was chosen because it comes with a proof of equivalence in strength to Diffie-Hellman; subtle flaws in some earlier encrypted key exchange protocols and implementations have encouraged us to take special care. In outline, the PAK protocol is:
-<DL><DT><DD><EM>C->S</EM>: <EM>C</EM>,<EM>gxH<br>
-S->C</EM>: <EM>S</EM>,<EM>gy</EM>,<EM>hash</EM>(<EM>gxy</EM>,<EM>C</EM>,<EM>S</EM>)<br>
-<EM>C->S</EM>: <EM>hash</EM>(<EM>gxy</EM>,<EM>S</EM>,<EM>C</EM>)<br>
-</DL>where <EM>H </EM>is a preshared secret between client <EM>C </EM>and server <EM>S</EM>. There are several variants of PAK, all presented in papers mainly concerned with proofs of cryptographic properties. To aid implementers, we have distilled a description of the specific version we use into an Appendix to this paper. The Plan 9 open source license provides for use of Lucent's encrypted key exchange patents in this context.
-  <P>
-As a further layer of defense against password theft, we provide (within the encrypted channel <EM>C->S</EM>) information that is validated at a RADIUS server, such as the digits from a hardware token [RFC2138]. This provides two-factor authentication, which potentially requires tricking two independent administrators in any attack by social engineering.
-  <P>
-The key file stored on the server is encrypted with AES (Rijndael) using CBC with a 10-byte initialization vector and trailing authentication padding. All this is invisible to the user of <TT>secstore</TT>. For that matter, it is invisible to the <TT>secstore</TT> server as well; if the AES Modes of Operation are standardized and a new encryption format designed, it can be implemented by a client without change to the server. The <TT>secstore</TT> is deliberately not backed up; the user is expected to use more than one <TT>secstore</TT> or save the key file on removable media and lock it away. The user's password is hashed to create the <EM>H </EM>used in the PAK protocol; a different hash of the password is used as the file encryption key. Finally, there is a command (inside the authenticated, encrypted channel between client and <TT>secstore</TT>) to change passwords by sending a new <EM>H</EM>; for consistency, the client process must at the same time fetch and re-encrypt all files.
-  <P>
-When <TT>factotum</TT> starts, it dials the local <TT>secstore</TT> and checks whether the user has an account. If so, it prompts for the user's <TT>secstore</TT> password and fetches the key file. The PAK protocol ensures mutual authentication and prevents dictionary attacks on the password by passive wiretappers or active intermediaries. Passwords saved in the key file can be long random strings suitable for simpler challenge/response authentication protocols. Thus the user need only remember a single, weaker password to enable strong, ``single sign on'' authentication to unchanged legacy applications scattered across multiple authentication domains.
-<H4>6. Transport Layer Security
+<TT>factotum</TT>
+must be
+supplemented by a persistent store, perhaps
+a floppy disk containing a key file of commands to be copied into
+<TT>/mnt/factotum/ctl</TT>
+during bootstrap.
+But removable media are a nuisance to carry and
+are vulnerable to theft.
+Keys could be stored encrypted on a shared file system, but
+only if those keys are not necessary for authenticating to
+the file system in the first place.
+Even if the keys are encrypted under a user
+password, a thief might well succeed with a dictionary attack.
+Other risks of local storage are loss of the contents
+through mechanical mishap or dead batteries.
+Thus for convenience and
+safety we provide a
+<TT>secstore</TT>
+(secure store) server in the network to hold each user's permanent list of keys, a
+<I>key</I>
+<I>file</I>.
+<br>&#32;<br>
+<TT>Secstore</TT>
+is a file server for encrypted data,
+used only during bootstrapping.
+It must provide strong
+authentication and resistance to passive and active protocol attacks
+while assuming nothing more from the client than a password.
+Once
+<TT>factotum</TT>
+has loaded the key file, further encrypted or authenticated
+file storage can be accomplished by standard mechanisms.
+<br><img src="-.19111514.gif"><br>
+<br>&#32;<br>
+The cryptographic technology that enables
+<TT>secstore</TT>
+is a form of encrypted
+key exchange
+called PAK
+[Boyk00],
+analogous to
+EKE
+[Bell93],
+SRP
+[Wu98],
+or
+SPEKE
+[Jabl].
+PAK was chosen
+because it comes with a proof of equivalence in strength to
+Diffie-Hellman; subtle flaws in some earlier encrypted key exchange
+protocols and implementations have encouraged us to take special care.
+In outline, the PAK protocol is:
+<DL><DT><DD><TT><PRE>
+n(1111&lt;I&gt;C&lt;/I&gt;-&gt;&lt;I&gt;S&lt;/I&gt;: &lt;I&gt;C&lt;/I&gt;,&lt;I&gt;g&lt;/I&gt;^&lt;I&gt;x&lt;/I&gt;11&lt;I&gt;H&lt;/I&gt;n(99
+n(1111&lt;I&gt;S&lt;/I&gt;-&gt;&lt;I&gt;C&lt;/I&gt;: &lt;I&gt;S&lt;/I&gt;,&lt;I&gt;g&lt;/I&gt;^&lt;I&gt;y&lt;/I&gt;11,&lt;I&gt;hash&lt;/I&gt;(&lt;I&gt;g&lt;/I&gt;^&lt;I&gt;xy&lt;/I&gt;11,&lt;I&gt;C&lt;/I&gt;,&lt;I&gt;S&lt;/I&gt;)n(99
+n(1111&lt;I&gt;C&lt;/I&gt;-&gt;&lt;I&gt;S&lt;/I&gt;: &lt;I&gt;hash&lt;/I&gt;(&lt;I&gt;g&lt;/I&gt;^&lt;I&gt;xy&lt;/I&gt;11,&lt;I&gt;S&lt;/I&gt;,&lt;I&gt;C&lt;/I&gt;)n(99
+</PRE></TT></DL>
+n(11where 11&lt;I&gt;H&lt;/I&gt;n(99 is a preshared secret between client 11&lt;I&gt;C&lt;/I&gt;n(99 and server 11&lt;I&gt;S&lt;/I&gt;n(99.
+There are several variants of PAK, all presented in papers
+mainly concerned with proofs of cryptographic properties.
+To aid implementers, we have distilled a description of the specific
+version we use into an Appendix to this paper.
+The Plan 9 open source license provides for use of Lucent's
+encrypted key exchange patents in this context.
+<br>&#32;<br>
+As a further layer of defense against password theft,
+n(11we provide (within the encrypted channel 11&lt;I&gt;C&lt;/I&gt;-&gt;&lt;I&gt;S&lt;/I&gt;n(99)
+information that is validated at a RADIUS server,
+such as the digits from a hardware token
+[RFC2138].
+This provides two-factor authentication, which potentially
+requires tricking two independent administrators in any attack by
+social engineering.
+<br>&#32;<br>
+The key file stored on the server is encrypted with AES (Rijndael) using CBC
+with a 10-byte initialization vector and trailing authentication padding.
+All this is invisible to the user of
+<TT>secstore</TT>.
+For that matter, it is invisible to the
+<TT>secstore</TT>
+server as well;
+if the AES Modes of Operation are standardized and a new encryption format
+designed, it can be implemented by a client without change to the server.
+The
+<TT>secstore</TT>
+is deliberately not backed up;  the user is expected to
+use more than one
+<TT>secstore</TT>
+or save the key file on removable media
+and lock it away.
+n(11The user's password is hashed to create the 11&lt;I&gt;H&lt;/I&gt;n(99 used
+in the PAK protocol;  a different hash of the password is used as
+the file encryption key.
+Finally, there is a command (inside the authenticated,
+encrypted channel between client and
+<TT>secstore</TT>)
+to change passwords by sending
+n(11a new 11&lt;I&gt;H&lt;/I&gt;n(99; 
+for consistency, the client process must at the same time fetch and re-encrypt all files.
+<br>&#32;<br>
+When
+<TT>factotum</TT>
+starts, it dials the local
+<TT>secstore</TT>
+and checks whether the user has an account.
+If so,
+it prompts for the user's
+<TT>secstore</TT>
+password and fetches the key file.
+The PAK protocol
+ensures mutual authentication and prevents dictionary attacks on the password
+by passive wiretappers or active intermediaries.
+Passwords saved in
+the key file can be long random strings suitable for
+simpler challenge/response authentication protocols.
+Thus the user need only remember
+a single, weaker password to enable strong, ``single sign on'' authentication to
+unchanged legacy applications scattered across multiple authentication domains.
+<H4>6 Transport Layer Security
 </H4>
-Since the Plan 9 operating system is designed for use in network elements that must withstand direct attack, unguarded by firewall or VPN, we seek to ensure that all applications use channels with appropriate mutual authentication and encryption. A principal tool for this is TLS 1.0 [RFC2246]. (TLS 1.0 is nearly the same as SSL 3.0, and our software is designed to interoperate with implementations of either standard.)
-  <P>
-TLS defines a record layer protocol for message integrity and privacy through the use of message digesting and encryption with shared secrets. We implement this service as a kernel device, though it could be performed at slightly higher cost by invoking a separate program. The library interface to the TLS kernel device is:
-<pre>
-    int pushtls(int fd, char *hashalg, char *cryptalg, int isclient,
-         char *secret, char *dir);
-</pre>
-Given a file descriptor, the names of message digest and encryption algorithms, and the shared secret, <TT>pushtls</TT> returns a new file descriptor for the encrypted connection. (The final argument <TT>dir</TT> receives the name of the directory in the TLS device that is associated with the new connection.) The function is named by analogy with the ``push'' operation supported by the stream I/O system of Research Unix and the first two editions of Plan 9. Because adding encryption is as simple as replacing one file descriptor with another, adding encryption to a particular network service is usually trivial.
-  <P>
-The Plan 9 shared key authentication protocols establish a shared 56-bit secret as a side effect. Native Plan 9 network services such as <TT>cpu</TT> and <TT>exportfs</TT> use these protocols for authentication and then invoke <TT>pushtls</TT> with the shared secret.<br>
-  <P>
-Above the record layer, TLS specifies a handshake protocol using public keys to establish the session secret. This protocol is widely used with HTTP and IMAP4 to provide server authentication, though with client certificates it could provide mutual authentication. The library function
-<DL><DT><DD><TT>int tlsClient(int fd, TLSconn *conn)<br>
-</TT></DL>handles the initial handshake and returns the result of <TT>pushtls</TT>. On return, it fills the <TT>conn</TT> structure with the session ID used and the X.509 certificate presented by the server, but makes no effort to verify the certificate. Although the original design intent of X.509 certificates expected that they would be used with a Public Key Infrastructure, reliable deployment has been so long delayed and problematic that we have adopted the simpler policy of just using the X.509 certificate as a representation of the public key, depending on a locally-administered directory of SHA1 thumbprints to allow applications to decide which public keys to trust for which purposes.
-<H4>7. Related Work and Discussion
+<br>&#32;<br>
+Since the Plan 9 operating system is designed for use in network elements
+that must withstand direct attack, unguarded by firewall or VPN, we seek
+to ensure that all applications use channels with appropriate mutual
+authentication and encryption.
+A principal tool for this is TLS 1.0
+[RFC2246].
+(TLS 1.0 is nearly the same as SSL 3.0,
+and our software is designed to interoperate
+with implementations of either standard.)
+<br>&#32;<br>
+TLS defines a record layer protocol for message integrity and privacy
+through the use of message digesting and encryption with shared secrets.
+We implement this service as a kernel device, though it could
+be performed at slightly higher cost by invoking a separate program.
+The library interface to the TLS kernel device is:
+<DL><DT><DD><TT><PRE>
+int pushtls(int fd, char *hashalg,
+    char *cryptalg, int isclient,
+    char *secret, char *dir);
+</PRE></TT></DL>
+Given a file descriptor, the names of message digest and
+encryption algorithms, and the shared secret,
+<TT>pushtls</TT>
+returns a new file descriptor for the encrypted connection.
+(The final argument
+<TT>dir</TT>
+receives the name of the directory in the TLS device that
+is associated with the new connection.)
+The function is named by analogy with the ``push'' operation
+supported by the stream I/O system of Research Unix and the
+first two editions of Plan 9.
+Because adding encryption is as simple as replacing one
+file descriptor with another, adding encryption to a particular
+network service is usually trivial.
+<br>&#32;<br>
+The Plan 9 shared key authentication protocols establish a shared 56-bit secret
+as a side effect.
+Native Plan 9 network services such as
+<TT>cpu</TT>
+and
+<TT>exportfs</TT>
+use these protocols for authentication and then invoke 
+<TT>pushtls</TT>
+with the shared secret.
+<br>&#32;<br>
+Above the record layer, TLS specifies a handshake protocol using public keys
+to establish the session secret.
+This protocol is widely used with HTTP and IMAP4
+to provide server authentication, though with client certificates it could provide
+mutual authentication.  The library function
+<DL><DT><DD><TT><PRE>
+int tlsClient(int fd, TLSconn *conn)
+</PRE></TT></DL>
+handles the initial handshake and returns the result of
+<TT>pushtls</TT>.
+On return, it fills the
+<TT>conn</TT>
+structure with the session ID used
+and the X.509 certificate presented by the
+server, but makes no effort to verify the certificate.
+Although the original design intent of X.509 certificates expected
+that they would be used with a Public Key Infrastructure,
+reliable deployment has been so long delayed and problematic
+that we have adopted the simpler policy of just using the
+X.509 certificate as a representation of the public key,
+depending on a locally-administered directory of SHA1 thumbprints
+to allow applications to decide which public keys to trust
+for which purposes.
+<H4>7 Related Work and Discussion
 </H4>
-Kerberos, one of the earliest distributed authentication systems, keeps a set of authentication tickets in a temporary file called a ticket cache. The ticket cache is protected by Unix file permissions. An environment variable containing the file name of the ticket cache allows for different ticket caches in different simultaneous login sessions. A user logs in by typing his or her Kerberos password. The login program uses the Kerberos password to obtain a temporary ticket-granting ticket from the authentication server, initializes the ticket cache with the ticket-granting ticket, and then forgets the password. Other applications can use the ticket-granting ticket to sign tickets for themselves on behalf of the user during the login session. The ticket cache is removed when the user logs out [Stei88]. The ticket cache relieves the user from typing a password every time authentication is needed.
-  <P>
-The secure shell SSH develops this idea further, replacing the temporary file with a named Unix domain socket connected to a user-level program, called an agent. Once the SSH agent is started and initialized with one or more RSA private keys, SSH clients can employ it to perform RSA authentications on their behalf. In the absence of an agent, SSH typically uses RSA keys read from encrypted disk files or uses passphrase-based authentication, both of which would require prompting the user for a passphrase whenever authentication is needed [Ylon96]. The self-certifying file system SFS uses a similar agent [Kami00], not only for moderating the use of client authentication keys but also for verifying server public keys [Mazi99].
-  <P>
-<TT>Factotum</TT> is a logical continuation of this evolution, replacing the program-specific SSH or SFS agents with a general agent capable of serving a wide variety of programs. Having one agent for all programs removes the need to have one agent for each program. It also allows the programs themselves to be protocol-agnostic, so that, for example, one could build an SSH workalike capable of using any protocol supported by <TT>factotum</TT>, without that program knowing anything about the protocols. Traditionally each program needs to implement each authentication protocol for itself, an <EM>O</EM>(<EM>n</EM>2) coding problem that <TT>factotum</TT> reduces to <EM>O</EM>(<EM>n</EM>).
-  <P>
-Previous work on agents has concentrated on their use by clients authenticating to servers. Looking in the other direction, Sun Microsystem's pluggable authentication module (PAM) is one of the earliest attempts to provide a general authentication mechanism for Unix-like operating systems [Sama96]. Without a central authority like PAM, system policy is tied up in the various implementations of network services. For example, on a typical Unix, if a system administrator decides not to allow plaintext passwords for authentication, the configuration files for a half dozen different servers -- <TT>rlogind</TT>, <TT>telnetd</TT>, <TT>ftpd</TT>, <TT>sshd</TT>, and so on -- need to be edited. PAM solves this problem by hiding the details of a given authentication mechanism behind a common library interface. Directed by a system-wide configuration file, an application selects a particular authentication mechanism by dynamically loading the appropriate shared library. PAM is widely used on Sun's Solaris and some Linux distributions.
-  <P>
-<TT>Factotum</TT> achieves the same goals using the agent approach. <TT>Factotum</TT> is the only process that needs to create capabilities, so all the network servers can run as untrusted users (e.g., Plan 9's <TT>none</TT> or Unix's <TT>nobody</TT>), which greatly reduces the harm done if a server is buggy and is compromised. In fact, if <TT>factotum</TT> were implemented on Unix along with an analogue to the Plan 9 capability device, venerable programs like <TT>su</TT> and <TT>login</TT> would no longer need to be installed ``setuid root.''
-  <P>
-Several other systems, such as Password Safe [Schn], store multiple passwords in an encrypted file, so that the user only needs to remember one password. Our <TT>secstore</TT> solution differs from these by placing the storage in a hardened location in the network, so that the encrypted file is less liable to be stolen for offline dictionary attack and so that it is available even when a user has several computers. In contrast, Microsoft's Passport system [Micr] keeps credentials in the network, but centralized at one extremely-high-value target. The important feature of Passport, setting up trust relationships with e-merchants, is outside our scope. The <TT>secstore</TT> architecture is almost identical to Perlman and Kaufman's [Perl99] but with newer EKE technology. Like them, we chose to defend mainly against outside attacks on <TT>secstore</TT>; if additional defense of the files on the server itself is desired, one can use distributed techniques [Ford00].
-  <P>
-We made a conscious choice of placing encryption, message integrity, and key management at the application layer (TLS, just above layer 4) rather than at layer 3, as in IPsec. This leads to a simpler structure for the network stack, easier integration with applications and, most important, easier network administration since we can recognize which applications are misbehaving based on TCP port numbers. TLS does suffer (relative to IPsec) from the possibility of forged TCP Reset, but we feel that this is adequately dealt with by randomized TCP sequence numbers. In contrast with other TLS libraries, Plan 9 does not require the application to change <TT>write</TT> calls to <TT>sslwrite</TT> but simply to add a few lines of code at startup [Resc01].
-<H4>8. Conclusion
+<br>&#32;<br>
+Kerberos, one of the earliest distributed authentication
+systems, keeps a set of authentication tickets in a temporary file called
+a ticket cache.  The ticket cache is protected by Unix file permissions.
+An environment variable containing the file name of the ticket cache
+allows for different ticket caches in different simultaneous login sessions.
+A user logs in by typing his or her Kerberos password.
+The login program uses the Kerberos password to obtain a temporary
+ticket-granting ticket from the authentication server, initializes the
+ticket cache with the ticket-granting ticket, and then forgets the password.
+Other applications can use the ticket-granting ticket to sign tickets
+for themselves on behalf of the user during the login session.
+The ticket cache is removed when the user logs out
+[Stei88].
+The ticket cache relieves the user from typing a password
+every time authentication is needed.
+<br>&#32;<br>
+The secure shell SSH develops this idea further, replacing the
+temporary file with a named Unix domain socket connected to
+a user-level program, called an agent.
+Once the SSH agent is started and initialized with one or
+more RSA private keys, SSH clients can employ it
+to perform RSA authentications on their behalf.
+In the absence of an agent, SSH typically uses RSA keys
+read from encrypted disk files or uses passphrase-based
+authentication, both of which would require prompting the user
+for a passphrase whenever authentication is needed
+[Ylon96].
+The self-certifying file system SFS uses a similar agent
+[Kami00],
+not only for moderating the use of client authentication keys 
+but also for verifying server public keys
+[Mazi99].
+<br>&#32;<br>
+<TT>Factotum</TT>
+is a logical continuation of this evolution,
+replacing the program-specific SSH or SFS agents with
+a general agent capable of serving a wide variety of programs.
+Having one agent for all programs removes the need
+to have one agent for each program.
+It also allows the programs themselves to be protocol-agnostic,
+so that, for example, one could build an SSH workalike
+capable of using any protocol supported by
+<TT>factotum</TT>,
+without that program knowing anything about the protocols.
+Traditionally each program needs to implement each
+n(11authentication protocol for itself, an 11&lt;I&gt;O&lt;/I&gt;(&lt;I&gt;n&lt;/I&gt;^211)n(99 coding
+problem that
+<TT>factotum</TT>
+n(11reduces to 11&lt;I&gt;O&lt;/I&gt;(&lt;I&gt;n&lt;/I&gt;)n(99.
+<br>&#32;<br>
+Previous work on agents has concentrated on their use by clients
+authenticating to servers.
+Looking in the other direction, Sun Microsystem's 
+pluggable authentication module (PAM) is one
+of the earliest attempts to 
+provide a general authentication mechanism for Unix-like 
+operating systems
+[Sama96].
+Without a central authority like PAM, system policy is tied
+up in the various implementations of network services.
+For example, on a typical Unix, if a system administrator
+decides not to allow plaintext passwords for authentication,
+the configuration files for a half dozen different servers &#173;
+<TT>rlogind</TT>,
+<TT>telnetd</TT>,
+<TT>ftpd</TT>,
+<TT>sshd</TT>,
+and so on &#173;
+need to be edited.
+PAM solves this problem by hiding the details of a given
+authentication mechanism behind a common library interface.
+Directed by a system-wide configuration file,
+an application selects a particular authentication mechanism
+by dynamically loading the appropriate shared library.
+PAM is widely used on Sun's Solaris and some Linux distributions.
+<br>&#32;<br>
+<TT>Factotum</TT>
+achieves the same goals
+using the agent approach.
+<TT>Factotum</TT>
+is the only process that needs to create
+capabilities, so all the network servers can run as 
+untrusted users (e.g.,
+Plan 9's
+<TT>none</TT>
+or Unix's
+<TT>nobody</TT>),
+which greatly reduces the harm done if a server is buggy
+and is compromised.
+In fact, if
+<TT>factotum</TT>
+were implemented on Unix along with
+an analogue to the Plan 9 capability device, venerable
+programs like
+<TT>su</TT>
+and
+<TT>login</TT>
+would no longer need to be installed ``setuid root.''
+<br>&#32;<br>
+Several other systems, such as Password Safe [Schn],
+store multiple passwords in an encrypted file,
+so that the user only needs to remember one password.
+Our
+<TT>secstore</TT>
+solution differs from these by placing the storage in
+a hardened location in the network, so that the encrypted file is
+less liable to be stolen for offline dictionary attack and so that
+it is available even when a user has several computers.
+In contrast, Microsoft's Passport system
+[Micr]
+keeps credentials in
+the network, but centralized at one extremely-high-value target.
+The important feature of Passport, setting up trust relationships
+with e-merchants, is outside our scope.
+The
+<TT>secstore</TT>
+architecture is almost identical to
+Perlman and Kaufman's
+[Perl99]
+but with newer EKE technology.
+Like them, we chose to defend mainly against outside attacks
+on
+<TT>secstore</TT>;
+if additional defense of the files on the server
+itself is desired, one can use distributed techniques
+[Ford00].
+<br>&#32;<br>
+We made a conscious choice of placing encryption, message integrity,
+and key management at the application layer
+(TLS, just above layer 4) rather than at layer 3, as in IPsec.
+This leads to a simpler structure for the network stack, easier
+integration with applications and, most important, easier network
+administration since we can recognize which applications are misbehaving
+based on TCP port numbers.  TLS does suffer (relative to IPsec) from
+the possibility of forged TCP Reset, but we feel that this is adequately
+dealt with by randomized TCP sequence numbers.
+In contrast with other TLS libraries, Plan 9 does not
+require the application to change
+<TT>write</TT>
+calls to
+<TT>sslwrite</TT>
+but simply to add a few lines of code at startup
+[Resc01].
+<H4>8 Conclusion
 </H4>
-Writing safe code is difficult. Stack attacks, mistakes in logic, and bugs in compilers and operating systems can each make it possible for an attacker to subvert the intended execution sequence of a service. If the server process has the privileges of a powerful user, such as <TT>root</TT> on Unix, then so does the attacker. <TT>Factotum</TT> allows us to constrain the privileged execution to a single process whose core is a few thousand lines of code. Verifying such a process, both through manual and automatic means, is much easier and less error prone than requiring it of all servers.
-  <P>
-An implementation of these ideas is in Plan 9 from Bell Labs, Fourth Edition, freely available from <A href=http://plan9.bell-labs.com/plan9><TT>http://plan9.bell-labs.com/plan9</TT>.</A>
-<H4>Acknowledgments<br>
+<br>&#32;<br>
+Writing safe code is difficult.
+Stack attacks,
+mistakes in logic, and bugs in compilers and operating systems
+can each make it possible for an attacker
+to subvert the intended execution sequence of a
+service.
+If the server process has the privileges
+of a powerful user, such as
+<TT>root</TT>
+on Unix, then so does the attacker.
+<TT>Factotum</TT>
+allows us
+to constrain the privileged execution to a single
+process whose core is a few thousand lines of code.
+Verifying such a process, both through manual and automatic means,
+is much easier and less error prone
+than requiring it of all servers.
+<br>&#32;<br>
+An implementation of these ideas is in Plan 9 from Bell Labs, Fourth Edition,
+freely available from <TT>http://plan9.bell-labs.com/plan9</TT>.
+<H4>Acknowledgments
 </H4>
-William Josephson contributed to the implementation of password changing in <TT>secstore</TT>. We thank Phil MacKenzie and Mart&iacute;n Abadi for helpful comments on early parts of the design. Chuck Blake, Peter Bosch, Frans Kaashoek, Sape Mullender, and Lakshman Y. N., predominantly Dutchmen, gave helpful comments on the paper. Russ Cox is supported by a fellowship from the Fannie and John Hertz Foundation.
-<H4>References<br>
+<br>&#32;<br>
+William Josephson contributed to the implementation of password changing in
+<TT>secstore</TT>.
+We thank Phil MacKenzie and Mart&iacute;n Abadi for helpful comments on early parts
+of the design.
+Chuck Blake,
+Peter Bosch,
+Frans Kaashoek,
+Sape Mullender,
+and
+Lakshman Y. N.,
+predominantly Dutchmen, gave helpful comments on the paper.
+Russ Cox is supported by a fellowship from the Fannie and John Hertz Foundation.
+<H4>References
 </H4>
-[Bell93] S.M. Bellovin and M. Merritt, ``Augmented Encrypted Key Exchange,'' Proceedings of the 1st ACM Conference on Computer and Communications Security, 1993, pp. 244 - 250.<br>
-  <P>
-[Boyk00] Victor Boyko, Philip MacKenzie, and Sarvar Patel, ``Provably Secure Password-Authenticated Key Exchange using Diffie-Hellman,'' Eurocrypt 2000, 156&#173;171.<br>
-  <P>
-[RFC2246] T . Dierks and C. Allen, ``The TLS Protocol, Version 1.0,'' RFC 2246.<br>
-  <P>
-[Ford00] Warwick Ford and Burton S. Kaliski, Jr., ``Server-Assisted Generation of a Strong Secret from a Password,'' IEEE Fifth International Workshop on Enterprise Security, National Institute of Standards and Technology (NIST), Gaithersburg MD, June 14 - 16, 2000.<br>
-  <P>
-[Jabl] David P. Jablon, ``Strong Password-Only Authenticated Key Exchange,'' <A href=http://integritysciences.com/speke97.html><TT>http://integritysciences.com/speke97.html</TT></A>.<br>
-  <P>
-[Kami00] Michael Kaminsky. ``Flexible Key Management with SFS Agents,'' Master's Thesis, MIT, May 2000.<br>
-  <P>
-[Mack] Philip MacKenzie, private communication.<br>
-  <P>
-[Mazi99] David Mazi&egrave;res, Michael Kaminsky, M. Frans Kaashoek and Emmett Witchel, ``Separating key management from file system security,'' Symposium on Operating Systems Principles, 1999, pp. 124-139.<br>
-  <P>
-[Micr] Microsoft Passport, <A href=http://www.passport.com/><TT>http://www.passport.com/</TT></A>.<br>
-  <P>
-[Perl99] Radia Perlman and Charlie Kaufman, ``Secure Password-Based Protocol for Downloading a Private Key,'' Proc. 1999 Network and Distributed System Security Symposium, Internet Society, January 1999.<br>
-  <P>
-[Pike95] Rob Pike, Dave Presotto, Sean Dorward, Bob Flandrena, Ken Thompson, Howard Trickey, and Phil Winterbottom, ``Plan 9 from Bell Labs,'' Computing Systems, 8, 3, Summer 1995, pp. 221-254.<br>
-  <P>
-[Pike93] Rob Pike, Dave Presotto, Ken Thompson, Howard Trickey, Phil Winterbottom, ``The Use of Name Spaces in Plan 9,'' Operating Systems Review, 27, 2, April 1993, pp. 72-76 (reprinted from Proceedings of the 5th ACM SIGOPS European Workshop, Mont Saint-Michel, 1992, Paper n&#186; 34).
-  <P>
-[Resc01] Eric Rescorla, ``SSL and TLS: Designing and Building Secure Systems,'' Addison-Wesley, 2001. ISBN 0-201-61598-3, p. 387.<br>
-  <P>
-[RFC2138] C. Rigney, A. Rubens, W. Simpson, S. Willens, ``Remote Authentication Dial In User Service (RADIUS),'' RFC2138, April 1997.<br>
-  <P>
-[RiLa] Ronald L. Rivest and Butler Lampson, ``SDSI--A Simple Distributed Security Infrastructure,'' <A href=http://theory.lcs.mit.edu/~rivest/sdsi10.ps><TT>http://theory.lcs.mit.edu/~rivest/sdsi10.ps</TT></A>.<br>
-  <P>
-[Schn] Bruce Schneier, Password Safe, <A href=http://www.counterpane.com/passsafe.html><TT>http://www.counterpane.com/passsafe.html</TT></A>.<br>
-  <P>
-[Sama96] Vipin Samar, ``Unified Login with Pluggable Authentication Modules (PAM),'' Proceedings of the Third ACM Conference on Computer Communications and Security, March 1996, New Delhi, India.<br>
-  <P>
-[Stei88] Jennifer G. Steiner, Clifford Neumann, and Jeffrey I. Schiller, ``<EM>Kerberos</EM>: An Authentication Service for Open Network Systems,'' Proceedings of USENIX Winter Conference, Dallas, Texas, February 1988, pp. 191&#173;202.<br>
-  <P>
-[Wu98] T. Wu, ``The Secure Remote Password Protocol,'' Proceedings of the 1998 Internet Society Network and Distributed System Security Symposium, San Diego, CA, March 1998, pp. 97-111.<br>
-  <P>
-[Ylon96] Ylonen, T., ``SSH--Secure Login Connections Over the Internet,'' 6th USENIX Security Symposium, pp. 37-42. San Jose, CA, July 1996.<br>
+<br>&#32;<br>
+[Bell93]
+S.M. Bellovin and M. Merritt,
+``Augmented Encrypted Key Exchange,''
+Proceedings of the 1st ACM Conference on Computer and Communications Security, 1993, pp. 244 - 250.
+<br>&#32;<br>
+[Boyk00]
+Victor Boyko, Philip MacKenzie, and Sarvar Patel,
+``Provably Secure Password-Authenticated Key Exchange using Diffie-Hellman,''
+Eurocrypt 2000, 156-171.
+<br>&#32;<br>
+[RFC2246]
+T . Dierks and C. Allen,
+``The TLS Protocol, Version 1.0,''
+RFC 2246.
+<br>&#32;<br>
+[Ford00]
+Warwick Ford and Burton S. Kaliski, Jr.,
+``Server-Assisted Generation of a Strong Secret from a Password,''
+IEEE Fifth International Workshop on Enterprise Security,
+National Institute of Standards and Technology (NIST),
+Gaithersburg MD, June 14 - 16, 2000.
+<br>&#32;<br>
+[Jabl]
+David P. Jablon,
+``Strong Password-Only Authenticated Key Exchange,''
+<TT>http://integritysciences.com/speke97.html</TT>.
+<br>&#32;<br>
+[Kami00]
+Michael Kaminsky.
+``Flexible Key Management with SFS Agents,''
+Master's Thesis, MIT, May 2000.
+<br>&#32;<br>
+[Mack]
+Philip MacKenzie,
+private communication.
+<br>&#32;<br>
+[Mazi99]
+David Mazi&egrave;res, Michael Kaminsky, M. Frans Kaashoek and Emmett Witchel,
+``Separating key management from file system security,''
+Symposium on Operating Systems Principles, 1999, pp. 124-139.
+<br>&#32;<br>
+[Micr]
+Microsoft Passport,
+<TT>http://www.passport.com/</TT>.
+<br>&#32;<br>
+[Perl99]
+Radia Perlman and Charlie Kaufman,
+``Secure Password-Based Protocol for Downloading a Private Key,''
+Proc. 1999 Network and Distributed System Security Symposium,
+Internet Society, January 1999.
+<br>&#32;<br>
+[Pike95]
+Rob Pike, Dave Presotto, Sean Dorward, Bob Flandrena, Ken Thompson, Howard Trickey, and Phil Winterbottom,
+``Plan 9 from Bell Labs,''
+Computing Systems, <B>8</B>, 3, Summer 1995, pp. 221-254.
+<br>&#32;<br>
+[Pike93]
+Rob Pike, Dave Presotto, Ken Thompson, Howard Trickey, Phil Winterbottom,
+``The Use of Name Spaces in Plan 9,''
+Operating Systems Review, <B>27</B>, 2, April 1993, pp. 72-76
+(reprinted from Proceedings of the 5th ACM SIGOPS European Workshop,
+Mont Saint-Michel, 1992, Paper n&#186; 34).
+<br>&#32;<br>
+[Resc01]
+Eric Rescorla,
+``SSL and TLS: Designing and Building Secure Systems,''
+Addison-Wesley, 2001. ISBN 0-201-61598-3, p. 387.
+<br>&#32;<br>
+[RFC2138]
+C. Rigney, A. Rubens, W. Simpson, S. Willens,
+``Remote Authentication Dial In User Service (RADIUS),''
+RFC2138, April 1997.
+<br>&#32;<br>
+[RiLa]
+Ronald L. Rivest and Butler Lampson,
+``SDSI&#173;A Simple Distributed Security Infrastructure,''
+<TT>http://theory.lcs.mit.edu/~rivest/sdsi10.ps</TT>.
+<br>&#32;<br>
+[Schn]
+Bruce Schneier, Password Safe,
+<TT>http://www.counterpane.com/passsafe.html</TT>.
+<br>&#32;<br>
+[Sama96]
+Vipin Samar,
+``Unified Login with Pluggable Authentication Modules (PAM),''
+Proceedings of the Third ACM Conference on Computer Communications and Security,
+March 1996, New Delhi, India.
+<br>&#32;<br>
+[Stei88]
+Jennifer G. Steiner, Clifford Neumann, and Jeffrey I. Schiller,
+``<I>Kerberos</I>: An Authentication Service for Open Network Systems,''
+Proceedings of USENIX Winter Conference, Dallas, Texas, February 1988, pp. 191-202.
+<br>&#32;<br>
+[Wu98]
+T. Wu,
+``The Secure Remote Password Protocol,''
+Proceedings of
+the 1998 Internet Society Network and Distributed System Security
+Symposium, San Diego, CA, March 1998, pp. 97-111.
+<br>&#32;<br>
+[Ylon96]
+Ylonen, T.,
+``SSH&#173;Secure Login Connections Over the Internet,''
+6th USENIX Security Symposium, pp. 37-42. San Jose, CA, July 1996.
 <H4>Appendix: Summary of the PAK protocol
 </H4>
-Let <EM>q&gt;</EM>2^160 and <EM>p&gt;</EM>2^1024 be primes such that <EM>p=rq+</EM>1 with <EM>r </EM>not a multiple of <EM>q</EM>. Take <EM>h∈Zp* </EM>such that <EM>g==h^r </EM>is not 1. These parameters may be chosen by the NIST algorithm for DSA, and are public, fixed values. The client <EM>C </EM>knows a secret π and computes <EM>H==</EM>(<EM>H</EM>1(<EM>C</EM>, π))<EM>r </EM>and <EM>H</EM>^-1, where <EM>H</EM>1 is a hash function yielding a random element of <EM>Zp*</EM>, and <EM>H</EM>^-1 may be computed by gcd. (All arithmetic is modulo <EM>p</EM>.) The client gives <EM>H</EM>^-1 to the server <EM>S </EM>ahead of time by a private channel. To start a new connection, the client generates a random value <EM>x</EM>, computes <EM>m==g^xH</EM>, then calls the server and sends <EM>C </EM>and <EM>m</EM>. The server checks <EM>m!=</EM>0 mod <EM>p</EM>, generates random <EM>y</EM>, computes μ==<EM>g^y</EM>, σ==(<EM>mH</EM>^-1)<EM>y</EM>, and sends <EM>S</EM>, μ, <EM>k==sha1</EM>(&quot;server&quot;,<EM>C</EM>,<EM>S</EM>,<EM>m</EM>,μ,σ,<EM>H-</EM>1). Next the client computes σ=μ<EM>x</EM>, verifies <EM>k</EM>, and sends <EM>k&#180;==sha1</EM>(&quot;client&quot;,<EM>C</EM>,<EM>S</EM>,<EM>m</EM>,μ,σ,<EM>H</EM>^-1). The server then verifies <EM>k&#180; </EM>and both sides begin using session key <EM>K==sha1</EM>(&quot;session&quot;,<EM>C</EM>,<EM>S</EM>,<EM>m</EM>,μ,σ,<EM>H</EM>^-1). In the published version of PAK, the server name <EM>S </EM>is included in the initial hash <EM>H</EM>, but doing so is inconvenient in our application, as the server may be known by various equivalent names.
-  <P>
-MacKenzie has shown [Mack] that the equivalence proof [Boyk00] can be adapted to cover our version.<br>
-
-<BR><FONT size=1><A HREF="http://www.lucent.com/copyright.html">
-Copyright</A> &#169; 2002 Lucent Technologies.  All rights reserved.</FONT>
-
-</BODY></HTML>
+<br>&#32;<br>
+n(11Let 11&lt;I&gt;q&gt;&lt;/I&gt;2^16011n(99 and 11&lt;I&gt;p&gt;&lt;/I&gt;2^102411n(99 be primes
+n(11such that 11&lt;I&gt;p=rq+&lt;/I&gt;1n(99 with 11&lt;I&gt;r&lt;/I&gt;n(99 not a multiple of 11&lt;I&gt;q&lt;/I&gt;n(99.
+^&lt;I&gt;*&lt;/I&gt;h'-0w'&lt;I&gt;*&lt;/I&gt;'u+0w'&lt;I&gt;*&lt;/I&gt;'u'11
+n(11Take 11&lt;I&gt;h&lt;/I&gt;&lt;I&gt;&isin;&lt;/I&gt;&lt;I&gt;Z&lt;/I&gt;&lt;I&gt;p&lt;/I&gt;h'-0w'&lt;I&gt;p&lt;/I&gt;'u'n(99 such that 11&lt;I&gt;g&lt;/I&gt;==&lt;I&gt;h&lt;/I&gt;^&lt;I&gt;r&lt;/I&gt;11n(99 is not 1.
+These parameters may be chosen by the NIST algorithm for DSA,
+and are public, fixed values.
+n(11The client 11&lt;I&gt;C&lt;/I&gt;n(99 knows a secret 11&#960;n(99
+n(11and computes 11&lt;I&gt;H&lt;/I&gt;==(&lt;I&gt;H&lt;/I&gt;111(&lt;I&gt;C&lt;/I&gt;, &#960;)&lt;I&gt;&lt;/I&gt;)^&lt;I&gt;r&lt;/I&gt;11n(99 and 11&lt;I&gt;H&lt;/I&gt;^&lt;I&gt;-&lt;/I&gt;111n(99,
+^&lt;I&gt;*&lt;/I&gt;h'-0w'&lt;I&gt;*&lt;/I&gt;'u+0w'&lt;I&gt;*&lt;/I&gt;'u'11
+n(11where 11&lt;I&gt;H&lt;/I&gt;111n(99 is a hash function yielding a random element of 11&lt;I&gt;Z&lt;/I&gt;&lt;I&gt;p&lt;/I&gt;h'-0w'&lt;I&gt;p&lt;/I&gt;'u'n(99,
+n(11and 11&lt;I&gt;H&lt;/I&gt;^&lt;I&gt;-&lt;/I&gt;111n(99 may be computed by gcd.
+n(11(All arithmetic is modulo 11&lt;I&gt;p&lt;/I&gt;n(99.)
+n(11The client gives 11&lt;I&gt;H&lt;/I&gt;^&lt;I&gt;-&lt;/I&gt;111n(99 to the server 11&lt;I&gt;S&lt;/I&gt;n(99 ahead of time by a private channel.
+n(11To start a new connection, the client generates a random value 11&lt;I&gt;x&lt;/I&gt;n(99,
+n(11computes 11&lt;I&gt;m&lt;/I&gt;==&lt;I&gt;g&lt;/I&gt;^&lt;I&gt;x&lt;/I&gt;11&lt;I&gt;H&lt;/I&gt;n(99,
+n(11then calls the server and sends 11&lt;I&gt;C&lt;/I&gt;n(99 and 11&lt;I&gt;m&lt;/I&gt;n(99.
+n(11The server checks 11&lt;I&gt;m&lt;/I&gt;!=0 mod &lt;I&gt;p&lt;/I&gt;n(99,
+n(11generates random 11&lt;I&gt;y&lt;/I&gt;n(99,
+n(11computes 11&#956;==&lt;I&gt;g&lt;/I&gt;^&lt;I&gt;y&lt;/I&gt;11n(99,
+n(1111&#963;==(&lt;I&gt;m&lt;/I&gt;&lt;I&gt;H&lt;/I&gt;^&lt;I&gt;-&lt;/I&gt;111)^&lt;I&gt;y&lt;/I&gt;11n(99,
+n(11and sends 11&lt;I&gt;S&lt;/I&gt;n(99, 11&#956;n(99, 11&lt;I&gt;k&lt;/I&gt;==&lt;I&gt;sha1&lt;/I&gt;("server",&lt;I&gt;C&lt;/I&gt;,&lt;I&gt;S&lt;/I&gt;,&lt;I&gt;m&lt;/I&gt;,&#956;,&#963;,&lt;I&gt;H&lt;/I&gt;^&lt;I&gt;-&lt;/I&gt;111)n(99.
+n(11Next the client computes 11&#963;&lt;I&gt;=&lt;/I&gt;&#956;^&lt;I&gt;x&lt;/I&gt;11n(99,
+n(11verifies 11&lt;I&gt;k&lt;/I&gt;n(99,
+n(11and sends 11&lt;I&gt;k&#180;&lt;/I&gt;==&lt;I&gt;sha1&lt;/I&gt;("client",&lt;I&gt;C&lt;/I&gt;,&lt;I&gt;S&lt;/I&gt;,&lt;I&gt;m&lt;/I&gt;,&#956;,&#963;,&lt;I&gt;H&lt;/I&gt;^&lt;I&gt;-&lt;/I&gt;111)n(99.
+n(11The server then verifies 11&lt;I&gt;k&#180;&lt;/I&gt;n(99 and both sides begin
+n(11using session key 11&lt;I&gt;K&lt;/I&gt;==&lt;I&gt;sha1&lt;/I&gt;("session",&lt;I&gt;C&lt;/I&gt;,&lt;I&gt;S&lt;/I&gt;,&lt;I&gt;m&lt;/I&gt;,&#956;,&#963;,&lt;I&gt;H&lt;/I&gt;^&lt;I&gt;-&lt;/I&gt;111)n(99.
+n(11In the published version of PAK, the server name 11&lt;I&gt;S&lt;/I&gt;n(99
+is included in the initial
+n(11hash 11&lt;I&gt;H&lt;/I&gt;n(99, but doing so is inconvenient in our application,
+as the server may be known by various equivalent names.
+<br>&#32;<br>
+MacKenzie has shown
+[Mack]
+that the
+equivalence proof [Boyk00]
+can be adapted to cover our version.
+<br>&#32;<br>
+<A href=http://www.lucent.com/copyright.html>
+Copyright</A> &#169; 2004 Lucent Technologies Inc.  All rights reserved.
+</body></html>

+ 114 - 115
sys/doc/comp.html

@@ -100,9 +100,9 @@ first in the machine-dependent directory and then
 in the machine-independent directory.
 At the time of writing there are thirty-one machine-independent include
 files and two (per machine) machine-dependent ones:
-<TT><ureg.h></TT>
+<TT>&lt;ureg.h&gt;</TT>
 and
-<TT><u.h></TT>.
+<TT>&lt;u.h&gt;</TT>.
 The first describes the layout of registers on the system stack,
 for use by the debugger.
 The second defines some
@@ -147,13 +147,13 @@ The type
 is the largest integer type available; on most architectures it
 is a 64-bit value.
 A couple of other types in
-<TT><u.h></TT>
+<TT>&lt;u.h&gt;</TT>
 are
 <TT>u32int</TT>,
 which is guaranteed to have exactly 32 bits (a possibility on all the supported architectures) and
 <TT>mpdigit</TT>,
 which is used by the multiprecision math package
-<TT><mp.h></TT>.
+<TT>&lt;mp.h&gt;</TT>.
 The
 <TT>#define</TT>
 constants permit an architecture-independent (but compiler-dependent)
@@ -165,12 +165,12 @@ and
 <P>
 Every Plan 9 C program begins
 <DL><DT><DD><TT><PRE>
-#include &#60;u.h&#62;
+#include &lt;u.h&gt;
 </PRE></TT></DL>
 because all the other installed header files use the
 <TT>typedefs</TT>
 declared in
-<TT><u.h></TT>.
+<TT>&lt;u.h&gt;</TT>.
 </P>
 <P>
 In strict ANSI C, include files are grouped to collect related functions
@@ -191,14 +191,14 @@ plus all the system calls and related functions.
 To use these functions, one must
 <TT>#include</TT>
 the file
-<TT><libc.h></TT>,
+<TT>&lt;libc.h&gt;</TT>,
 which in turn must follow
-<TT><u.h></TT>,
+<TT>&lt;u.h&gt;</TT>,
 to define their prototypes for the compiler.
 Here is the complete source to the traditional first C program:
 <DL><DT><DD><TT><PRE>
-#include &#60;u.h&#62;
-#include &#60;libc.h&#62;
+#include &lt;u.h&gt;
+#include &lt;libc.h&gt;
 
 void
 main(void)
@@ -226,13 +226,13 @@ All these functions are, of course, documented in the Programmer's Manual.
 <P>
 To use
 <TT>printf</TT>,
-<TT><stdio.h></TT>
+<TT>&lt;stdio.h&gt;</TT>
 must be included to define the function prototype for
 <TT>printf</TT>:
 <DL><DT><DD><TT><PRE>
-#include &#60;u.h&#62;
-#include &#60;libc.h&#62;
-#include &#60;stdio.h&#62;
+#include &lt;u.h&gt;
+#include &lt;libc.h&gt;
+#include &lt;stdio.h&gt;
 
 void
 main(int argc, char *argv[])
@@ -351,7 +351,7 @@ that may be run (on a 680X0 machine):
 </PRE></TT></DL>
 The loader automatically links with whatever libraries the program
 needs, usually including the standard C library as defined by
-<TT><libc.h></TT>.
+<TT>&lt;libc.h&gt;</TT>.
 Of course the compiler and loader have lots of options, both familiar and new;
 see the manual for details.
 The compiler does not generate an executable automatically;
@@ -447,34 +447,34 @@ When the system starts or a user logs in the environment is configured
 so the appropriate binaries are available in
 <TT>/bin</TT>.
 The configuration process is controlled by an environment variable,
-<TT>$cputype</TT>,
+<TT></TT><I>cputype</I><TT>,
 with value such as
-<TT>mips</TT>,
-<TT>68020</TT>,
-<TT>386</TT>,
+</TT><TT>mips</TT><TT>,
+</TT><TT>68020</TT><TT>,
+</TT><TT>386</TT><TT>,
 or
-<TT>sparc</TT>.
+</TT><TT>sparc</TT><TT>.
 For each architecture there is a directory in the root,
 with the appropriate name,
 that holds the binary and library files for that architecture.
 Thus
-<TT>/mips/lib</TT>
+</TT><TT>/mips/lib</TT><TT>
 contains the object code libraries for MIPS programs,
-<TT>/mips/include</TT>
+</TT><TT>/mips/include</TT><TT>
 holds MIPS-specific include files, and
-<TT>/mips/bin</TT>
+</TT><TT>/mips/bin</TT><TT>
 has the MIPS binaries.
 These binaries are attached to
-<TT>/bin</TT>
+</TT><TT>/bin</TT><TT>
 at boot time by binding
-<TT>/$cputype/bin</TT>
+</TT><TT>/</TT><TT>cputype/bin</TT><TT>
 to
-<TT>/bin</TT>,
+</TT><TT>/bin</TT><TT>,
 so
-<TT>/bin</TT>
+</TT><TT>/bin</TT><TT>
 always contains the correct files.
 </P>
-<P>
+</TT><P>
 The MIPS compiler,
 <TT>vc</TT>,
 by definition
@@ -493,11 +493,11 @@ If one is running on a SPARC,
 <TT>/sparc/bin/vc</TT>
 will compile programs for the MIPS;
 if one is running on machine
-<TT>$cputype</TT>,
-<TT>/$cputype/bin/vc</TT>
+<TT></TT><I>cputype</I><TT>,
+</TT><TT>/</TT><TT>cputype/bin/vc</TT><TT>
 will compile programs for the MIPS.
 </P>
-<P>
+</TT><P>
 Because of the bindings that assemble
 <TT>/bin</TT>,
 the shell always looks for a command, say
@@ -505,20 +505,20 @@ the shell always looks for a command, say
 in
 <TT>/bin</TT>
 and automatically finds the file
-<TT>/$cputype/bin/date</TT>.
+<TT>/</TT><I>cputype/bin/date</I><TT>.
 Therefore the MIPS compiler is known as just
-<TT>vc</TT>;
+</TT><TT>vc</TT><TT>;
 the shell will invoke
-<TT>/bin/vc</TT>
+</TT><TT>/bin/vc</TT><TT>
 and that is guaranteed to be the version of the MIPS compiler
 appropriate for the machine running the command.
 Regardless of the architecture of the compiling machine,
-<TT>/bin/vc</TT>
+</TT><TT>/bin/vc</TT><TT>
 is
-<I>always</I>
+</TT><I>always</I><TT>
 the MIPS compiler.
 </P>
-<P>
+</TT><P>
 Also, the output of
 <TT>vc</TT>
 and
@@ -554,27 +554,27 @@ makes it easy to compile the source into binary suitable for any architecture.
 </P>
 <P>
 The variable
-<TT>$cputype</TT>
+<TT></TT>cputype<TT>
 is advisory: it reports the architecture of the current environment, and should
 not be modified.  A second variable,
-<TT>$objtype</TT>,
+</TT><TT></TT><I>objtype</I><TT>,
 is used to set which architecture is being
-<I>compiled</I>
+</TT><I>compiled</I><TT>
 for.
 The value of
-<TT>$objtype</TT>
+</TT><TT></TT><TT>objtype</TT><TT>
 can be used by a
-<TT>mkfile</TT>
+</TT><TT>mkfile</TT><TT>
 to configure the compilation environment.
 </P>
-<P>
+</TT><P>
 In each machine's root directory there is a short
 <TT>mkfile</TT>
 that defines a set of macros for the compiler, loader, etc.
 Here is
 <TT>/mips/mkfile</TT>:
 <DL><DT><DD><TT><PRE>
-&#60;/sys/src/mkfile.proto
+&lt;/sys/src/mkfile.proto
 
 CC=vc
 LD=vl
@@ -583,7 +583,7 @@ AS=va
 </PRE></TT></DL>
 The line
 <DL><DT><DD><TT><PRE>
-&#60;/sys/src/mkfile.proto
+&lt;/sys/src/mkfile.proto
 </PRE></TT></DL>
 causes
 <TT>mk</TT>
@@ -621,72 +621,72 @@ Here is a
 to build the installed source for
 <TT>sam</TT>:
 <DL><DT><DD><TT><PRE>
-&#60;/$objtype/mkfile
-OBJ=sam.$O address.$O buffer.$O cmd.$O disc.$O error.$O \
-	file.$O io.$O list.$O mesg.$O moveto.$O multi.$O \
-	plan9.$O rasp.$O regexp.$O string.$O sys.$O xec.$O
+&lt;/<I>objtype/mkfile
+OBJ=sam.</I>O address.<I>O buffer.</I>O cmd.<I>O disc.</I>O error.<I>O \
+	file.</I>O io.<I>O list.</I>O mesg.<I>O moveto.</I>O multi.<I>O \
+	plan9.</I>O rasp.<I>O regexp.</I>O string.<I>O sys.</I>O xec.<I>O
 
-$O.out:	$OBJ
-	$LD $OBJ
+</I>O.out:	<I>OBJ
+	</I>LD <I>OBJ
 
-install:	$O.out
-	cp $O.out /$objtype/bin/sam
+install:	</I>O.out
+	cp <I>O.out /</I>objtype/bin/sam
 
 installall:
-	for(objtype in $CPUS) mk install
+	for(objtype in <I>CPUS) mk install
 
-%.$O:	%.c
-	$CC $CFLAGS $stem.c
+%.</I>O:	%.c
+	<I>CC </I>CFLAGS <I>stem.c
 
-$OBJ:	sam.h errors.h mesg.h
-address.$O cmd.$O parse.$O xec.$O unix.$O:	parse.h
+</I>OBJ:	sam.h errors.h mesg.h
+address.<I>O cmd.</I>O parse.<I>O xec.</I>O unix.<I>O:	parse.h
 
 clean:V:
-	rm -f [$OS].out *.[$OS] y.tab.?
+	rm -f [</I>OS].out *.[<I>OS] y.tab.?
 </PRE></TT></DL>
 (The actual
-<TT>mkfile</TT>
+</I><TT>mkfile</TT><I>
 imports most of its rules from other secondary files, but
 this example works and is not misleading.)
 The first line causes
-<TT>mk</TT>
+</I><TT>mk</TT><I>
 to include the contents of
-<TT>/$objtype/mkfile</TT>
+</I><TT>/</TT><I>objtype/mkfile</I><TT>
 in the current
-<TT>mkfile</TT>.
+</TT><TT>mkfile</TT><TT>.
 If
-<TT>$objtype</TT>
+</TT><TT></TT><I>objtype</I><TT>
 is
-<TT>mips</TT>,
+</TT><TT>mips</TT><TT>,
 this inserts the MIPS macro definitions into the
-<TT>mkfile</TT>.
+</TT><TT>mkfile</TT><TT>.
 In this case the rule for
-<TT>$O.out</TT>
+</TT><TT></TT><TT>O.out</TT><TT>
 uses the MIPS tools to build
-<TT>v.out</TT>.
+</TT><TT>v.out</TT><TT>.
 The
-<TT>%.$O</TT>
+</TT><TT>%.</TT><I>O</I><TT>
 rule in the file uses
-<TT>mk</TT>'s
+</TT><TT>mk</TT><TT>'s
 pattern matching facilities to convert the source files to the object
 files through the compiler.
 (The text of the rules is passed directly to the shell,
-<TT>rc</TT>,
+</TT><TT>rc</TT><TT>,
 without further translation.
 See the
-<TT>mk</TT>
+</TT><TT>mk</TT><TT>
 manual if any of this is unfamiliar.)
 Because the default rule builds
-<TT>$O.out</TT>
+</TT><TT></TT><TT>O.out</TT><TT>
 rather than
-<TT>sam</TT>,
+</TT><TT>sam</TT><TT>,
 it is possible to maintain binaries for multiple machines in the
 same source directory without conflict.
 This is also, of course, why the output files from the various
 compilers and loaders
 have distinct names.
 </P>
-<P>
+</TT><P>
 The rest of the
 <TT>mkfile</TT>
 should be easy to follow; notice how the rules for
@@ -695,21 +695,21 @@ and
 <TT>installall</TT>
 (that is, install versions for all architectures) use other macros
 defined in
-<TT>/$objtype/mkfile</TT>.
+<TT>/</TT><I>objtype/mkfile</I><TT>.
 In Plan 9,
-<TT>mkfiles</TT>
+</TT><TT>mkfiles</TT><TT>
 for commands conventionally contain rules to
-<TT>install</TT>
+</TT><TT>install</TT><TT>
 (compile and install the version for
-<TT>$objtype</TT>),
-<TT>installall</TT>
+</TT><TT></TT><TT>objtype</TT><TT>),
+</TT><TT>installall</TT><TT>
 (compile and install for all
-<TT>$objtypes</TT>),
+</TT><TT></TT><I>objtypes</I><TT>),
 and
-<TT>clean</TT>
+</TT><TT>clean</TT><TT>
 (remove all object files, binaries, etc.).
 </P>
-<P>
+</TT><P>
 The
 <TT>mkfile</TT>
 is easy to use.  To build a MIPS binary,
@@ -769,10 +769,10 @@ getlong(void)
 {
 	ulong l;
 
-	l = (getchar()&amp;0xFF)&#60;&#60;24;
-	l |= (getchar()&amp;0xFF)&#60;&#60;16;
-	l |= (getchar()&amp;0xFF)&#60;&#60;8;
-	l |= (getchar()&amp;0xFF)&#60;&#60;0;
+	l = (getchar()&amp;0xFF)&lt;&lt;24;
+	l |= (getchar()&amp;0xFF)&lt;&lt;16;
+	l |= (getchar()&amp;0xFF)&lt;&lt;8;
+	l |= (getchar()&amp;0xFF)&lt;&lt;0;
 	return l;
 }
 </PRE></TT></DL>
@@ -805,7 +805,7 @@ and hope that the target machine supports ANSI C and POSIX.
 </H4>
 <P>
 The default C library, defined by the include file
-<TT><libc.h></TT>,
+<TT>&lt;libc.h&gt;</TT>,
 contains no buffered I/O package.
 It does have several entry points for printing formatted text:
 <TT>print</TT>
@@ -821,7 +821,7 @@ explicitly include the header file associated with an appropriate library.
 The recommended I/O library, used by most Plan 9 utilities, is
 <TT>bio</TT>
 (buffered I/O), defined by
-<TT><bio.h></TT>.
+<TT>&lt;bio.h&gt;</TT>.
 There also exists an implementation of ANSI Standard I/O,
 <TT>stdio</TT>.
 </P>
@@ -840,9 +840,9 @@ does not predefine them.  Here is a program to copy input to output a byte
 at a time using
 <TT>bio</TT>:
 <DL><DT><DD><TT><PRE>
-#include &#60;u.h&#62;
-#include &#60;libc.h&#62;
-#include &#60;bio.h&#62;
+#include &lt;u.h&gt;
+#include &lt;libc.h&gt;
+#include &lt;bio.h&gt;
 
 Biobuf	bin;
 Biobuf	bout;
@@ -976,8 +976,8 @@ For more information, see the Programmer's Manual, in particular
 <A href="/magic/man2html/2/rune"><I>rune</I>(2),
 </A>and the paper,
 ``Hello world, or
-&#191;ALPHA&#191;&#191;MU&#191;&#191;ALPHA &#191;&#191;&#191;MUEPSILON, or 
-&#191;&#191;&#191;&#191;&#191; &#191;&#191;'',
+&#922;&#945;&#955;&#951;&#956;&#941;&#961;&#945; &#954;&#972;&#963;&#956;&#949;, or 
+&#12371;&#12435;&#12395;&#12385;&#12399; &#19990;&#30028;'',
 by Rob Pike and
 Ken Thompson;
 there is not room for the full story here.
@@ -1004,7 +1004,7 @@ representation of the characters
 The type
 <TT>Rune</TT>
 is defined in
-<TT><u.h></TT>
+<TT>&lt;u.h&gt;</TT>
 to be
 <TT>ushort</TT>,
 which is also the  `wide character' type in the compiler.
@@ -1055,14 +1055,14 @@ Finally, although it's not ANSI C, the Plan 9 C compilers
 assume any character with value above
 <TT>Runeself</TT>
 is an alphanumeric,
-so ALPHA is a legal, if non-portable, variable name.
+so &#945; is a legal, if non-portable, variable name.
 </P>
 <H4>Arguments
 </H4>
 <P>
 Some macros are defined
 in
-<TT><libc.h></TT>
+<TT>&lt;libc.h&gt;</TT>
 for parsing the arguments to
 <TT>main()</TT>.
 They are described in
@@ -1184,12 +1184,12 @@ struct Node
 void	lock(struct Lock*);
 </PRE></TT></DL>
 one may refer to
-<TT>node->type</TT>,
-<TT>node->dval</TT>,
-<TT>node->fval</TT>,
-<TT>node->lval</TT>,
+<TT>node-&gt;type</TT>,
+<TT>node-&gt;dval</TT>,
+<TT>node-&gt;fval</TT>,
+<TT>node-&gt;lval</TT>,
 and
-<TT>node->locked</TT>.
+<TT>node-&gt;locked</TT>.
 Moreover, the address of a
 <TT>struct</TT>
 <TT>Node</TT>
@@ -1436,42 +1436,42 @@ language to format and display data structure types defined in the program.
 The easiest way to use this feature is to put a rule in the
 <TT>mkfile</TT>:
 <DL><DT><DD><TT><PRE>
-syms:   main.$O
-        $CC -a main.c &#62; syms
+syms:   main.O
+        <I>CC -a main.c &gt; syms
 </PRE></TT></DL>
 Then from within
-<TT>acid</TT>,
+</I><TT>acid</TT><I>,
 <DL><DT><DD><TT><PRE>
 acid: include("sourcedirectory/syms")
 </PRE></TT></DL>
 to read in the relevant definitions.
 (For multi-file source, you need to be a little fancier;
 see
-<A href="/magic/man2html/1/2c"><I>2c</I>(1)).
+<A href="/magic/man2html/1/2c"></I><I>2c</I><I>(1)).
 </A>This text includes, for each defined compound
 type, a function with that name that may be called with the address of a structure
 of that type to display its contents.
 For example, if
-<TT>rect</TT>
+</I><TT>rect</TT><I>
 is a global variable of type
-<TT>Rectangle</TT>,
+</I><TT>Rectangle</TT><I>,
 one may execute
 <DL><DT><DD><TT><PRE>
 Rectangle(*rect)
 </PRE></TT></DL>
 to display it.
 The
-<TT>*</TT>
+</I><TT>*</TT><I>
 (indirection) operator is necessary because
 of the way
-<TT>acid</TT>
+</I><TT>acid</TT><I>
 works: each global symbol in the program is defined as a variable by
-<TT>acid</TT>,
+</I><TT>acid</TT><I>,
 with value equal to the
-<I>address</I>
+</I><I>address</I><I>
 of the symbol.
 </P>
-<P>
+</I><P>
 Another common technique is to write by hand special
 <TT>acid</TT>
 code to define functions to aid debugging, initialize the debugger, and so on.
@@ -1505,9 +1505,8 @@ There is much more to say here.  See
 manual page, the reference manual, or the paper
 ``Acid: A Debugger Built From A Language'',
 also by Phil Winterbottom.
-
 </P>
 <br>&#32;<br>
 <A href=http://www.lucent.com/copyright.html>
-Copyright</A> &#169; 2000 Lucent Technologies Inc.  All rights reserved.
+Copyright</A> &#169; 2004 Lucent Technologies Inc.  All rights reserved.
 </body></html>

+ 51 - 27
sys/doc/compiler.html

@@ -54,15 +54,15 @@ The names of the compliers, loaders, and assemblers
 are as follows:
 <DL><DT><DD><TT><PRE>
 SPARC	<TT>kc</TT>  <TT>kl</TT>  <TT>ka</TT>
-Power PC	<TT>qc</TT>  <TT>ql</TT>  <TT>qa</TT>
+Power	<TT>PC</TT>  <TT>qc</TT>  <TT>ql</TT>
 MIPS	<TT>vc</TT>  <TT>vl</TT>  <TT>va</TT>
-Motorola 68000	<TT>1c</TT>  <TT>1l</TT>  <TT>1a</TT>
-Motorola 68020	<TT>2c</TT>  <TT>2l</TT>  <TT>2a</TT>
-ARM 7500	<TT>5c</TT>  <TT>5l</TT>  <TT>5a</TT>
-Intel 960	<TT>6c</TT>  <TT>6l</TT>  <TT>6a</TT>
-DEC Alpha	<TT>7c</TT>  <TT>7l</TT>  <TT>7a</TT>
-Intel 386	<TT>8c</TT>  <TT>8l</TT>  <TT>8a</TT>
-AMD 29000	<TT>9c</TT>  <TT>9l</TT>  <TT>9a</TT>
+Motorola	<TT>68000</TT>  <TT>1c</TT>  <TT>1l</TT>
+Motorola	<TT>68020</TT>  <TT>2c</TT>  <TT>2l</TT>
+ARM	<TT>7500</TT>  <TT>5c</TT>  <TT>5l</TT>
+Intel	<TT>960</TT>  <TT>6c</TT>  <TT>6l</TT>
+DEC	<TT>Alpha</TT>  <TT>7c</TT>  <TT>7l</TT>
+Intel	<TT>386</TT>  <TT>8c</TT>  <TT>8l</TT>
+AMD	<TT>29000</TT>  <TT>9c</TT>  <TT>9l</TT>
 </PRE></TT></DL>
 There is a further breakdown
 in the source of the compilers into
@@ -171,9 +171,9 @@ One use of this feature allows references to elements of the
 subunit to be accessed as if they were in
 the outer structure.
 Thus
-<TT>node->dval</TT>
+<TT>node-&gt;dval</TT>
 and
-<TT>node->locked</TT>
+<TT>node-&gt;locked</TT>
 are legitimate references.
 <br>&#32;<br>
 When an outer structure is used
@@ -216,7 +216,7 @@ the type name (it must be a
 <TT>typedef</TT>)
 of the unnamed structure can be used as an identifier.
 In our example,
-<TT>&node->Lock</TT>
+<TT>&node-&gt;Lock</TT>
 gives the address of the anonymous
 <TT>Lock</TT>
 structure.
@@ -360,6 +360,26 @@ to be laid out in memory tightly packed in successive bytes, disregarding
 the usual alignment rules.
 Accessing such data can cause faults.
 <br>&#32;<br>
+Similarly, 
+<TT>#pragma</TT>
+<TT>profile</TT>
+<TT>off</TT>
+(or
+<TT>no</TT>
+or
+<TT>0</TT>)
+causes subsequently declared functions, until
+<TT>#pragma</TT>
+<TT>profile</TT>
+<TT>on</TT>
+(or
+<TT>yes</TT>
+or
+<TT>1</TT>),
+to be marked as unprofiled.
+Such functions will not be profiled when 
+profiling is enabled for the rest of the program.
+<br>&#32;<br>
 Two
 <TT>#pragma</TT>
 statements allow type-checking of
@@ -592,27 +612,32 @@ In the table,
 a node represented by the left column is marked
 with a small integer from the right column.
 Marks of the form
-addressable<TT>A<sub>i</sub></TT>are
+<TT>A<small><small><sub>i</sub></small></small></TT>
+are addressable while
 marks of the form
-not<TT>N<sub>i</sub></TT>are
+<TT>N<small><small><sub>i</sub></small></small></TT>
+are not addressable.
 <DL><DT><DD><TT><PRE>
 	Node	Marked
-	name	A<sub>1</sub>
-	const	A<sub>2</sub>
-	&amp;A<sub>1</sub>	A<sub>3</sub>
-	A<sub>3</sub>A<sub>1</sub>	N<sub>1</sub> (note that this is not addressable)
-	*N<sub>1</sub>	A<sub>4</sub>
+	name	A<small><small><sub>1</sub></small></small>
+	const	A<small><small><sub>2</sub></small></small>
+	&amp;A<small><small><sub>1</sub></small></small>	A<small><small><sub>3</sub></small></small>
+	A<small><small><sub>3</sub></small></small>+A<small><small><sub>1</sub></small></small>	N<small><small><sub>1</sub></small></small> (note that this is not addressable)
+	*N<small><small><sub>1</sub></small></small>	A<small><small><sub>4</sub></small></small>
 </PRE></TT></DL>
 Here there is a distinction between
 a node marked
-a<TT>A<sub>1</sub></TT>and
-the<TT>A<sub>4</sub></TT>because
-is<TT>A<sub>4</sub></TT>node
+<TT>A<small><small><sub>1</sub></small></small></TT>
+and a node marked
+<TT>A<small><small><sub>4</sub></small></small></TT>
+because the address operator of an
+<TT>A<small><small><sub>4</sub></small></small></TT>
+node is not addressable.
 So to extend the table:
 <DL><DT><DD><TT><PRE>
 	Node	Marked
-	&amp;A<sub>4</sub>	N<sub>2</sub>
-	N<sub>2</sub>N<sub>1</sub>	N<sub>1</sub>
+	&amp;A<small><small><sub>4</sub></small></small>	N<small><small><sub>2</sub></small></small>
+	N<small><small><sub>2</sub></small></small>+N<small><small><sub>1</sub></small></small>	N<small><small><sub>1</sub></small></small>
 </PRE></TT></DL>
 The full addressability of the 68020 is expressed
 in 18 rules like this,
@@ -782,7 +807,7 @@ table.
 The pattern is in the left column and the
 replacement action is in the right column.
 <DL><DT><DD><TT><PRE>
-	MOVE	a-&#62;b		(remove)
+	MOVE	a-&gt;b		(remove)
 	(sequence with no mention of <TT>a</TT>)
 	USE	b		USE	a
 	(sequence with no mention of <TT>a</TT>)
@@ -818,7 +843,7 @@ rewrite is in the right column.
 	(sequence with no use of <TT>b</TT>)
 	USE	a		USE	b
 	(sequence with no use of <TT>b</TT>)
-	MOVE	a-&#62;b		MOVE	b-&#62;a
+	MOVE	a-&gt;b		MOVE	b-&gt;a
 </PRE></TT></DL>
 Iterating these transformations
 will usually get rid of all redundant ``move'' instructions.
@@ -1086,8 +1111,7 @@ Vol 17(4), pp. 715-728, 1970.
 ``Assembling Code for Machines with Span-dependent Instructions'',
 Communications of the ACM,
 Vol 21(4), pp. 300-308, 1978.
-
 <br>&#32;<br>
 <A href=http://www.lucent.com/copyright.html>
-Copyright</A> &#169; 2000 Lucent Technologies Inc.  All rights reserved.
+Copyright</A> &#169; 2004 Lucent Technologies Inc.  All rights reserved.
 </body></html>

File diff suppressed because it is too large
+ 632 - 621
sys/doc/compiler.ps


+ 46 - 47
sys/doc/lexnames.html

@@ -61,9 +61,9 @@ open file or the current directory.
 Consider the following unedited transcript of a session running the Bourne shell on a modern
 Unix system:
 <DL><DT><DD><TT><PRE>
-% echo $HOME
+% echo <I>HOME
 /home/rob
-% cd $HOME
+% cd </I>HOME
 % pwd
 /n/bopp/v7/rob
 % cd /home/rob
@@ -83,8 +83,8 @@ It is, of course, the consequence of a series of symbolic links intended to give
 the illusion they share a disk, when in fact their files are scattered over several devices:
 <DL><DT><DD><TT><PRE>
 % ls -ld /home/rob /home/ken
-lrwxr-xr-x  1 root  sys   14 Dec 26  1998 /home/ken -&#62; /n/bopp/v6/ken
-lrwxr-xr-x  1 root  sys   14 Dec 23  1998 /home/rob -&#62; /n/bopp/v7/rob
+lrwxr-xr-x  1 root  sys   14 Dec 26  1998 /home/ken -&gt; /n/bopp/v6/ken
+lrwxr-xr-x  1 root  sys   14 Dec 23  1998 /home/rob -&gt; /n/bopp/v7/rob
 % 
 </PRE></TT></DL>
 The introduction of symbolic links has changed the Unix file system from a true
@@ -142,20 +142,20 @@ involve some lexical processing (somewhat like the
 function discussed later
 in this paper), augmented by heuristics such as examining the environment
 for names like
-<TT>$HOME</TT>
+<TT></TT><I>HOME</I><TT>
 and
-<TT>$PWD</TT>
+</TT><TT></TT><TT>PWD</TT><TT>
 to assist initialization of the state of the private view. [Korn00]
-<br>&#32;<br>
+</TT><br>&#32;<br>
 This transcript begins with a Bourne shell running:
 <DL><DT><DD><TT><PRE>
 % cd /home/rob
 % pwd
 /n/bopp/v7/rob
 % ksh
-$ pwd
+<I> pwd
 /home/rob
-$ 
+</I> 
 </PRE></TT></DL>
 This result is encouraging.  Another example, again starting from a Bourne shell:
 <DL><DT><DD><TT><PRE>
@@ -163,12 +163,12 @@ This result is encouraging.  Another example, again starting from a Bourne shell
 % cd ../ken
 ../ken: bad directory
 % ksh
-$ pwd
+<I> pwd
 /home/rob
-$ cd ../ken
-$ pwd
+</I> cd ../ken
+<I> pwd
 /home/ken
-$
+</I>
 </PRE></TT></DL>
 By doing extra work,
 the Korn shell is providing more sensible behavior,
@@ -181,16 +181,16 @@ but it is easy to defeat:
 % pwd
 /n/bopp/v7/rob/bin
 % ksh
-$ pwd
+<I> pwd
 /n/bopp/v7/rob/bin
-$ exit
+</I> exit
 % cd /home/ken
 % pwd
 /n/bopp/v6/ken
 % ksh
-$ pwd
+<I> pwd
 /n/bopp/v6/ken
-$ 
+</I> 
 </PRE></TT></DL>
 In these examples,
 <TT>ksh</TT>'s
@@ -330,17 +330,17 @@ to contain first the standard binaries, then the contents of
 private SPARC binaries.
 The ability to build such union directories
 obviates the need for a shell
-<TT>$PATH</TT>
+<TT></TT><I>PATH</I><TT>
 variable
 while providing opportunities for managing heterogeneity.
 If the system were a Power PC, the same sequence would be run with
-<TT>power</TT>
+</TT><TT>power</TT><TT>
 textually substituted for
-<TT>sparc</TT>
+</TT><TT>sparc</TT><TT>
 to place the Power PC binaries in
-<TT>/bin</TT>
+</TT><TT>/bin</TT><TT>
 rather than the SPARC binaries.
-<br>&#32;<br>
+</TT><br>&#32;<br>
 Trouble is already brewing.  After these bindings are set up,
 where does
 <DL><DT><DD><TT><PRE>
@@ -511,13 +511,13 @@ for
 <DT><DT>&#32;<DD>
 The parent of a directory
 <I>X</I>,
-<I>X<TT>/..</TT>,</I>
+<I>X</I><TT>/..</TT>,<TT>
 is the same directory that would obtain if
 we instead accessed the directory named by stripping away the last
 path name element of
-<I>X</I>.
+</TT><I>X</I><TT>.
 </dl>
-<br>&#32;<br>
+</TT><br>&#32;<br>
 For example, if we are in the directory
 <TT>/a/b/c</TT>
 and
@@ -624,13 +624,13 @@ Moreover, the presence of a full file name for each
 in the mount table provides the information necessary to resolve ambiguities.
 <br>&#32;<br>
 The mount table is examined in the
-<TT>from->to</TT>
+<TT>from</TT>-><TT>to</TT>
 direction when evaluating a name, but
 <TT>..</TT>
 points backwards in the hierarchy, so to evaluate
 <TT>..</TT>
 the table must be examined in the
-<TT>to->from</TT>
+<TT>to</TT>-><TT>from</TT>
 direction.
 (``How did we get here?'')
 <br>&#32;<br>
@@ -926,11 +926,11 @@ getwd(char *buf, int nbuf)
 	int n, fd;
 
 	fd = open(".", OREAD);
-	if(fd &#60; 0)
+	if(fd &lt; 0)
 		return NULL;
 	n = fd2path(fd, buf, nbuf);
 	close(fd);
-	if(n &#60; 0)
+	if(n &lt; 0)
 		return NULL;
 	return buf;
 }
@@ -957,8 +957,8 @@ openfiles(void)
 	int i;
 	char buf[256];
 
-	for(i=0; i&#60;NFD; i++)
-		if(fd2path(i, buf, sizeof buf) &#62;= 0)
+	for(i=0; i&lt;NFD; i++)
+		if(fd2path(i, buf, sizeof buf) &gt;= 0)
 			print("%d: %s\n", i, buf);
 }
 </PRE></TT></DL>
@@ -991,13 +991,13 @@ file system [Kill84].
 For process
 <I>n</I>,
 the file
-<TT>/proc/<I>n</I>/fd</TT>
+<TT>/proc/</TT><I>n</I><TT>/fd</TT><I>
 is a list of all its open files, including its working directory,
 with associated information including its open status,
 I/O offset, unique id (analogous to i-number)
 and file name.
 Here is the contents of the
-<TT>fd</TT>
+</I><TT>fd</TT><I>
 file for a process in the window system on the machine being used to write this paper:
 <DL><DT><DD><TT><PRE>
 % cat /proc/125099/fd 
@@ -1013,11 +1013,11 @@ file for a process in the window system on the machine being used to write this
 % 
 </PRE></TT></DL>
 (The Linux implementation of
-<TT>/proc</TT>
+</I><TT>/proc</TT><I>
 provides a related service by giving a directory in which each file-descriptor-numbered file is
 a symbolic link to the file itself.)
 When debugging errant systems software, such information can be valuable.
-<br>&#32;<br>
+</I><br>&#32;<br>
 Another motivation for getting names right was the need to extract from the system
 an accurate description of the mount table, so that a process's name space could be
 recreated on another machine, in order to move (or simulate) a computing environment
@@ -1029,7 +1029,7 @@ fast multiprocessor.
 Without accurate names, it was impossible to do the job right; now
 <TT>/proc</TT>
 provides a description of the name space of each process,
-<TT>/proc/<I>n</I>/ns</TT>:
+<TT>/proc/</TT><I>n</I><TT>/ns</TT><I>:
 <DL><DT><DD><TT><PRE>
 % cat /proc/125099/ns
 bind  / /
@@ -1060,28 +1060,28 @@ cd /usr/rob
 % 
 </PRE></TT></DL>
 (The
-<TT>#</TT>
+</I><TT>#</TT><I>
 notation identifies raw device drivers so they may be attached to the name space.)
 The last line of the file gives the working directory of the process.
 The format of this file is that used by a library routine,
-<TT>newns</TT>,
+</I><TT>newns</TT><I>,
 which reads a textual description like this and reconstructs a name space.
 Except for the need to quote
-<TT>#</TT>
+</I><TT>#</TT><I>
 characters, the output is also a shell script that invokes the user-level commands
-<TT>bind</TT>
+</I><TT>bind</TT><I>
 and
-<TT>mount</TT>,
+</I><TT>mount</TT><I>,
 which are just interfaces to the underlying system calls.
 However,
 files like
-<TT>/net/il/134/data</TT>
+</I><TT>/net/il/134/data</TT><I>
 represent network connections; to find out where they point, so that the corresponding
 calls can be reestablished for another process,
 they must be examined in more detail using the network device files [PrWi93].  Another program,
-<TT>ns</TT>,
+</I><TT>ns</TT><I>,
 does this; it reads the
-<TT>/proc/<I>n</I>/ns</TT>
+</I><TT>/proc/</TT><I>n</I><TT>/ns</TT><I>
 file, decodes the information, and interprets it, translating the network
 addresses and quoting the names when required:
 <DL><DT><DD><TT><PRE>
@@ -1096,7 +1096,7 @@ name space and recreate it elsewhere.
 And like the open file descriptor table,
 they are a boon to debugging; it is always helpful to know
 exactly what resources a program is using.
-<H4>Adapting to Unix
+</I><H4>Adapting to Unix
 </H4>
 <br>&#32;<br>
 This work was done for the Plan 9 operating system, which has the advantage that
@@ -1214,8 +1214,7 @@ Dave Presotto and Phil Winterbottom,
 ``The Organization of Networks in Plan 9'',
 <I>Proceedings of the Winter 1993 USENIX Conference</I>,
 San Diego, 1993, pp. 43-50.
-
 <br>&#32;<br>
 <A href=http://www.lucent.com/copyright.html>
-Copyright</A> &#169; 2000 Lucent Technologies Inc.  All rights reserved.
+Copyright</A> &#169; 2004 Lucent Technologies Inc.  All rights reserved.
 </body></html>

+ 100 - 100
sys/doc/libmach.html

@@ -78,32 +78,32 @@ to reflect the addition of the new architecture.
 </H4>
 <br>&#32;<br>
 Architecture-dependent headers are stored in directory
-<TT>/&lt;I&gt;m&lt;/I&gt;/include</TT>
+<TT>/</TT><I>m</I><TT>/include</TT><I>
 where
-<I>m</I>
+</I><I>m</I><I>
 is the name of the architecture (e.g.,
-<TT>mips</TT>).
+</I><TT>mips</TT><I>).
 Two header files are required:
-<TT>u.h</TT>
+</I><TT>u.h</TT><I>
 and
-<TT>ureg.h</TT>.
+</I><TT>ureg.h</TT><I>.
 The first defines fundamental data types,
 bit settings for the floating point
 status and control registers, and
-<TT>va_list</TT>
+</I><TT>va_list</TT><I>
 processing which depends on the stack
 model for the architecture.  This file
 is best built by copying and modifying the
-<TT>u.h</TT>
+</I><TT>u.h</TT><I>
 file from an architecture
 with a similar stack model.
 The
-<TT>ureg.h</TT>
+</I><TT>ureg.h</TT><I>
 file
 contains a structure describing the layout
 of the saved register set for
 the architecture; it is defined by the kernel.
-<br>&#32;<br>
+</I><br>&#32;<br>
 Header file
 <TT>/sys/include/a.out.h</TT>
 contains the definitions of the magic
@@ -270,24 +270,24 @@ The remainder provides the following processing
 of executable files or memory images:
 <DL><DD>
 <br>&#32;<br>
-<DL COMPACT>
-<DT>*<DD>
+<UL>
+<LI>
 Header interpretation.
-<DT>*<DD>
+<LI>
 Symbol table interpretation.
-<DT>*<DD>
+<LI>
 Execution context interpretation, such as stack traces
 and stack frame location.
-<DT>*<DD>
+<LI>
 Instruction interpretation including disassembly and
 instruction size and follow-set calculations.
-<DT>*<DD>
+<LI>
 Exception and floating point number interpretation.
-<DT>*<DD>
+<LI>
 Architecture-independent read and write access through a
 relocation map.
 </DL>
-</dl>
+</ul>
 <br>&#32;<br>
 Header file
 <TT>/sys/include/mach.h</TT>
@@ -402,57 +402,57 @@ A variety of symbol table access functions then support
 queries on the reformatted table.
 <DT>Debugger Support - <DD>
 Files named
-<TT>&lt;I&gt;m&lt;/I&gt;.c</TT>,
+<TT></TT><I>m</I><TT>.c</TT><I>,
 where
-<I>m</I>
+</I><I>m</I><I>
 is the code letter assigned to the architecture,
 contain the initialized
-<TT>Mach</TT>
+</I><TT>Mach</TT><I>
 data structure and the definition of the register
 set for each architecture.
 Architecture-specific debugger support functions and
 an initialized
-<TT>Machdata</TT>
+</I><TT>Machdata</TT><I>
 structure are stored in
 files named
-<TT>&lt;I&gt;m&lt;/I&gt;db.c</TT>.
+</I><TT></TT><I>m</I><TT>db.c</TT><I>.
 Files
-<TT>machdata.c</TT>
+</I><TT>machdata.c</TT><I>
 and
-<TT>setmach.c</TT>
+</I><TT>setmach.c</TT><I>
 contain debugger support functions shared
 by multiple architectures.
 <DT>Architecture-Independent Access - <DD>
 Files
-<TT>map.c</TT>,
-<TT>access.c</TT>,
+</I><TT>map.c</TT><I>,
+</I><TT>access.c</TT><I>,
 and
-<TT>swap.c</TT>
+</I><TT>swap.c</TT><I>
 provide accesses through a relocation map
 to data in an executable file or executing image.
 Byte-swapping is performed as needed.  Global variables
-<TT>mach</TT>
+</I><TT>mach</TT><I>
 and
-<TT>machdata</TT>
+</I><TT>machdata</TT><I>
 must point to the
-<TT>Mach</TT>
+</I><TT>Mach</TT><I>
 and
-<TT>Machdata</TT>
+</I><TT>Machdata</TT><I>
 data structures of the target architecture.
 <DT>Object File Interpretation - <DD>
 These files contain functions to identify the
 target architecture of an
 intermediate object file
 and extract references to symbols.  File
-<TT>obj.c</TT>
+</I><TT>obj.c</TT><I>
 contains code common to all architectures;
 file
-<TT>&lt;I&gt;m&lt;/I&gt;obj.c</TT>
+</I><TT></TT><I>m</I><TT>obj.c</TT><I>
 contains the architecture-specific source code
 for the machine with code character
-<I>m</I>.
+</I><I>m</I><I>.
 </dl>
-<br>&#32;<br>
+</I><br>&#32;<br>
 The
 <TT>Machdata</TT>
 data structure is primarily a jump
@@ -527,66 +527,66 @@ A symbolic code for the object file.
 <DL COMPACT>
 <DT>2.<DD>
 In a file name
-<TT>/sys/src/libmach/&lt;I&gt;m&lt;/I&gt;.c</TT>
+<TT>/sys/src/libmach/</TT><I>m</I><TT>.c</TT><I>
 (where
-<I>m</I>
+</I><I>m</I><I>
 is the identifier character assigned to the architecture),
 initialize
-<TT>Reglist</TT>
+</I><TT>Reglist</TT><I>
 and
-<TT>Mach</TT>
+</I><TT>Mach</TT><I>
 data structures with values defining
 the register set and various system parameters.
 The source file for a similar architecture
 can serve as template.
 Most of the fields of the
-<TT>Mach</TT>
+</I><TT>Mach</TT><I>
 data structure are obvious
 but a few require further explanation.
 <DL><DD>
-<DT>&lt;TT&gt;kbase&lt;/TT&gt; - <DD>
+<DT></I><TT>kbase</TT><I> - <DD>
 This field
 contains the address of the kernel 
-<TT>ublock</TT>.
+</I><TT>ublock</TT><I>.
 The debuggers
 assume the first entry of the kernel
-<TT>ublock</TT>
+</I><TT>ublock</TT><I>
 points to the
-<TT>Proc</TT>
+</I><TT>Proc</TT><I>
 structure for a kernel thread.
-<DT>&lt;TT&gt;ktmask&lt;/TT&gt; - <DD>
+<DT></I><TT>ktmask</TT><I> - <DD>
 This field
 is a bit mask used to calculate the kernel text address from
 the kernel 
-<TT>ublock</TT>
+</I><TT>ublock</TT><I>
 address.
 The first page of the
 kernel text segment is calculated by
 ANDing
 the negation of this mask with
-<TT>kbase</TT>.
-<DT>&lt;TT&gt;kspoff&lt;/TT&gt; - <DD>
+</I><TT>kbase</TT><I>.
+<DT></I><TT>kspoff</TT><I> - <DD>
 This field
 contains the byte offset in the
-<TT>Proc</TT>
+</I><TT>Proc</TT><I>
 data structure to the saved kernel
 stack pointer for a suspended kernel thread.  This
 is the offset to the 
-<TT>sched.sp</TT>
+</I><TT>sched.sp</TT><I>
 field of a
-<TT>Proc</TT>
+</I><TT>Proc</TT><I>
 table entry.
-<DT>&lt;TT&gt;kpcoff&lt;/TT&gt; - <DD>
+<DT></I><TT>kpcoff</TT><I> - <DD>
 This field contains the byte offset into the
-<TT>Proc</TT>
+</I><TT>Proc</TT><I>
 data structure
 of
 the program counter of a suspended kernel thread.
 This is the offset to
 field
-<TT>sched.pc</TT>
+</I><TT>sched.pc</TT><I>
 in that structure.
-<DT>&lt;TT&gt;kspdelta&lt;/TT&gt; and &lt;TT&gt;kpcdelta&lt;/TT&gt; - <DD>
+<DT></I><TT>kspdelta</TT><I> and </I><TT>kpcdelta</TT><I> - <DD>
 These fields
 contain corrections to be added to
 the stack pointer and program counter, respectively,
@@ -594,32 +594,32 @@ to properly locate the stack and next
 instruction of a kernel thread.  These
 values bias the saved registers retrieved
 from the
-<TT>Label</TT>
+</I><TT>Label</TT><I>
 structure named
-<TT>sched</TT>
+</I><TT>sched</TT><I>
 in the
-<TT>Proc</TT>
+</I><TT>Proc</TT><I>
 data structure.
 Most architectures require no bias
 and these fields contain zeros.
-<DT>&lt;TT&gt;scalloff&lt;/TT&gt; - <DD>
+<DT></I><TT>scalloff</TT><I> - <DD>
 This field
 contains the byte offset of the
-<TT>scallnr</TT>
+</I><TT>scallnr</TT><I>
 field in the
-<TT>ublock</TT>
+</I><TT>ublock</TT><I>
 data structure associated with a process.
 The
-<TT>scallnr</TT>
+</I><TT>scallnr</TT><I>
 field contains the number of the
 last system call executed by the process.
 The location of the field varies depending on
 the size of the floating point register set
 which precedes it in the
-<TT>ublock</TT>.
+</I><TT>ublock</TT><I>.
 </DL>
 </dl>
-<br>&#32;<br>
+</I><br>&#32;<br>
 <DL COMPACT>
 <DT>3.<DD>
 Add an entry to the initialization of the
@@ -700,9 +700,9 @@ architecture can be adopted with minor modifications.
 <DT>4.<DD>
 Write an object file parser and
 store it in file
-<TT>/sys/src/libmach/&lt;I&gt;m&lt;/I&gt;obj.c</TT>
+<TT>/sys/src/libmach/</TT><I>m</I><TT>obj.c</TT><I>
 where
-<I>m</I>
+</I><I>m</I><I>
 is the identifier character assigned to the architecture.
 Two functions are required: a predicate to identify an
 object file for the architecture and a function to extract
@@ -714,9 +714,9 @@ with minor modifications.
 When these
 functions are in hand, insert their addresses
 in the jump table at the beginning of file
-<TT>/sys/src/libmach/obj.c</TT>.
+</I><TT>/sys/src/libmach/obj.c</TT><I>.
 </dl>
-<br>&#32;<br>
+</I><br>&#32;<br>
 <DL COMPACT>
 <DT>5.<DD>
 Implement the required debugger support functions and
@@ -725,58 +725,58 @@ initialize the parameters and jump table of the
 data structure for the architecture.
 This code is conventionally stored in
 a file named
-<TT>/sys/src/libmach/&lt;I&gt;m&lt;/I&gt;db.c</TT>
+<TT>/sys/src/libmach/</TT><I>m</I><TT>db.c</TT><I>
 where
-<I>m</I>
+</I><I>m</I><I>
 is the identifier character assigned to the architecture.
 The fields of the
-<TT>Machdata</TT>
+</I><TT>Machdata</TT><I>
 structure are:
 <DL><DD>
-<DT>&lt;TT&gt;bpinst&lt;/TT&gt; and &lt;TT&gt;bpsize&lt;/TT&gt; - <DD>
+<DT></I><TT>bpinst</TT><I> and </I><TT>bpsize</TT><I> - <DD>
 These fields
 contain the breakpoint instruction and the size
 of the instruction, respectively.
-<DT>&lt;TT&gt;swab&lt;/TT&gt; - <DD>
+<DT></I><TT>swab</TT><I> - <DD>
 This field
 contains the address of a function to
 byte-swap a 16-bit value.  Choose
-<TT>leswab</TT>
+</I><TT>leswab</TT><I>
 or
-<TT>beswab</TT>
+</I><TT>beswab</TT><I>
 for little-endian or big-endian architectures, respectively.
-<DT>&lt;TT&gt;swal&lt;/TT&gt; - <DD>
+<DT></I><TT>swal</TT><I> - <DD>
 This field
 contains the address of a function to
 byte-swap a 32-bit value.  Choose
-<TT>leswal</TT>
+</I><TT>leswal</TT><I>
 or
-<TT>beswal</TT>
+</I><TT>beswal</TT><I>
 for little-endian or big-endian architectures, respectively.
-<DT>&lt;TT&gt;ctrace&lt;/TT&gt; - <DD>
+<DT></I><TT>ctrace</TT><I> - <DD>
 This field
 contains the address of a function to perform a
 C-language stack trace.  Two general trace functions,
-<TT>risctrace</TT>
+</I><TT>risctrace</TT><I>
 and
-<TT>cisctrace</TT>,
+</I><TT>cisctrace</TT><I>,
 traverse fixed-frame and relative-frame stacks,
 respectively.  If the compiler for the
 new architecture conforms to one of
 these models, select the appropriate function.  If the
 stack model is unique,
 supply a custom stack trace function.
-<DT>&lt;TT&gt;findframe&lt;/TT&gt; - <DD>
+<DT></I><TT>findframe</TT><I> - <DD>
 This field
 contains the address of a function to locate the stack
 frame associated with a text address.
 Generic functions
-<TT>riscframe</TT>
+</I><TT>riscframe</TT><I>
 and
-<TT>ciscframe</TT>
+</I><TT>ciscframe</TT><I>
 process fixed-frame and relative-frame stack
 models.
-<DT>&lt;TT&gt;ufixup&lt;/TT&gt; - <DD>
+<DT></I><TT>ufixup</TT><I> - <DD>
 This field
 contains the address of a function to adjust
 the base address of the register save area.
@@ -784,7 +784,7 @@ Currently, only the
 68020 requires this bias
 to offset over the active
 exception frame.
-<DT>&lt;TT&gt;excep&lt;/TT&gt; - <DD>
+<DT></I><TT>excep</TT><I> - <DD>
 This field
 contains the address of a function to produce a
 text
@@ -792,49 +792,49 @@ string describing the
 current exception.
 Each architecture stores exception
 information uniquely, so this code must always be supplied.
-<DT>&lt;TT&gt;bpfix&lt;/TT&gt; - <DD>
+<DT></I><TT>bpfix</TT><I> - <DD>
 This field
 contains the address of a function to adjust an
 address prior to laying down a breakpoint.
-<DT>&lt;TT&gt;sftos&lt;/TT&gt; - <DD>
+<DT></I><TT>sftos</TT><I> - <DD>
 This field
 contains the address of a function to convert a single
 precision floating point value
 to a string.  Choose
-<TT>leieeesftos</TT>
+</I><TT>leieeesftos</TT><I>
 for little-endian
 or
-<TT>beieeesftos</TT>
+</I><TT>beieeesftos</TT><I>
 for big-endian architectures.
-<DT>&lt;TT&gt;dftos&lt;/TT&gt; - <DD>
+<DT></I><TT>dftos</TT><I> - <DD>
 This field
 contains the address of a function to convert a double
 precision floating point value
 to a string.  Choose
-<TT>leieeedftos</TT>
+</I><TT>leieeedftos</TT><I>
 for little-endian
 or
-<TT>beieeedftos</TT>
+</I><TT>beieeedftos</TT><I>
 for big-endian architectures.
-<DT>&lt;TT&gt;foll&lt;/TT&gt;, &lt;TT&gt;das&lt;/TT&gt;, &lt;TT&gt;hexinst&lt;/TT&gt;, and &lt;TT&gt;instsize&lt;/TT&gt; - <DD>
+<DT></I><TT>foll</TT><I>, </I><TT>das</TT><I>, </I><TT>hexinst</TT><I>, and </I><TT>instsize</TT><I> - <DD>
 These fields point to functions that interpret machine
 instructions.
 They rely on disassembly of the instruction
 and are unique to each architecture.
-<TT>Foll</TT>
+</I><TT>Foll</TT><I>
 calculates the follow set of an instruction.
-<TT>Das</TT>
+</I><TT>Das</TT><I>
 disassembles a machine instruction to assembly language.
-<TT>Hexinst</TT>
+</I><TT>Hexinst</TT><I>
 formats a machine instruction as a text
 string of
 hexadecimal digits.
-<TT>Instsize</TT>
+</I><TT>Instsize</TT><I>
 calculates the size in bytes, of an instruction.
 Once the disassembler is written, the other functions
 can usually be implemented as trivial extensions of it.
 </dl>
-<br>&#32;<br>
+</I><br>&#32;<br>
 It is possible to provide support for a new architecture
 incrementally by filling the jump table entries
 of the
@@ -906,5 +906,5 @@ and load with
 </dl>
 <br>&#32;<br>
 <A href=http://www.lucent.com/copyright.html>
-Copyright</A> &#169; 2002 Lucent Technologies Inc.  All rights reserved.
+Copyright</A> &#169; 2004 Lucent Technologies Inc.  All rights reserved.
 </body></html>

+ 81 - 82
sys/doc/lp.html

@@ -88,17 +88,17 @@ Commands related to
 <I>lp</I>
 that are not shell scripts can most often be found
 in
-<TT>/$cputype/bin/aux</TT>.
+<TT>/</TT><I>cputype/bin/aux</I><TT>.
 The directory where all the
-<I>lp</I>
+</TT><I>lp</I><TT>
 scripts  reside is defined within
-<I>lp</I>
+</TT><I>lp</I><TT>
 by the shell variable
-<TT>LPLIB</TT>.
+</TT><TT>LPLIB</TT><TT>.
 In the remainder of this document, file names will be specified
 with this shell variable as their root.
 </P>
-<H4>2 Usage
+</TT><H4>2 Usage
 </H4>
 <P>
 <I>Lp</I>
@@ -109,31 +109,31 @@ This can be done in any of three ways described here.
 <DL COMPACT>
 <DT>1)<DD>
 The file
-<TT>$LPLIB/defdevice</TT>
+<TT></TT>LPLIB/defdevice<TT>
 may contain the name of a default output device.
 This may not be practical for environments where
 there are many printers.
 <DT>2)<DD>
 The user's environment variable
-<TT>LPDEST</TT>
+</TT><TT>LPDEST</TT><TT>
 may be set to the name of the device to be used.
 This is often a more practical solution when there are several printers
 available.
 This overrides a
-<TT>defdevice</TT>
+</TT><TT>defdevice</TT><TT>
 specification.
 <DT>3)<DD>
 The
-<TT>-d</TT>
-<I>printer</I>
+</TT><TT>-d</TT><TT>
+</TT><I>printer</I><TT>
 option to the
-<I>lp</I>
+</TT><I>lp</I><TT>
 command specifies
-<I>printer</I>
+</TT><I>printer</I><TT>
 as the device to which output should be directed, overriding the
 previous two specifications.
 </dl>
-<P>
+</TT><P>
 <br>
 If
 <I>printer</I>
@@ -191,7 +191,7 @@ with
 A file can be converted to PostScript using the pseudo-printer
 <TT>stdout</TT>:
 <DL><DT><DD><TT><PRE>
-% troff -ms lp.ms | lp -dstdout &#62; lp.ps
+% troff -ms lp.ms | lp -dstdout &gt; lp.ps
 </PRE></TT></DL>
 LaTeX (and analogously TeX)
 documents are printed in two steps:
@@ -234,10 +234,10 @@ The format of the status and queue printout is up to the administrator.
 The job started above can be killed with
 <TT>-k</TT>:
 <DL><DT><DD><TT><PRE>
-$ lp -dpsu -k rice29436.1
+<I> lp -dpsu -k rice29436.1
 rice29436.1 removed from psu queue on cetus
 </PRE></TT></DL>
-<H4>3 Options
+</I><H4>3 Options
 </H4>
 <P>
 There are options available to modify the way in which a job is handled.
@@ -251,7 +251,7 @@ Table 1 lists the standard
 options, the shell variable settings, and description of the options.
 
 <br>&#32;<br>
-<br><img src="data.15750.gif"><br>
+<br><img src="data.19118320.gif"><br>
 <br>&#32;<br>
 <I>Table 1. Lp Option List</I>
 <br>&#32;<br>
@@ -282,59 +282,59 @@ or as specified by the shell environment variable
 <TT>LPDEST</TT>
 or as specified by
 the file
-<TT>$LPLIB/defdevice</TT>.
+<TT></TT>LPLIB/defdevice<TT>.
 This name is used in creating directories and log files that are associated with
 the printers operation.
-<DT><TT>0<DD>
-LOC0</TT> just describes where the printer is physically located.
-<DT><TT>0<DD>
-DEST_HOST0</TT> is the host from which the files are printed.
+<DT></TT><TT>0<DD>
+LOC0</TT><TT> just describes where the printer is physically located.
+<DT></TT><TT>0<DD>
+DEST_HOST0</TT><TT> is the host from which the files are printed.
 Files may be spooled on other machines before being transferred to the
 destination host.
-<DT><TT>0<DD>
-OUT_DEV0</TT> is the physical device name or network address needed by the printer daemon
+<DT></TT><TT>0<DD>
+OUT_DEV0</TT><TT> is the physical device name or network address needed by the printer daemon
 to connect to the printer.
 This field depends on the requirements of the daemon and may contain a `&#191;'
 if not required.
-<DT><TT>0<DD>
-SPEED0</TT> is the baud rate setting for the port.
+<DT></TT><TT>0<DD>
+SPEED0</TT><TT> is the baud rate setting for the port.
 This field depends on the requirements of the daemon and may contain a `&#191;'
 if not required.
-<DT><TT>0<DD>
-LPCLASS0</TT> is used to encode minor printer differences.
+<DT></TT><TT>0<DD>
+LPCLASS0</TT><TT> is used to encode minor printer differences.
 The keyword
-<TT>reverse</TT>
+</TT><TT>reverse</TT><TT>
 is used by some of the preprocessors
 to reverse the order the pages are printed to accommodate different output
 trays (either face up or face down).
 The keyword
-<TT>nohead</TT>
+</TT><TT>nohead</TT><TT>
 is used to suppress the header page.
 This is used for special and color printers.
 The keyword
-<TT>duplex</TT>
+</TT><TT>duplex</TT><TT>
 is used to coax double sided output from duplex printers.
-<DT><TT>0<DD>
-LPPROC0</TT> is the command from the
-<TT>LPLIB/process</TT>
+<DT></TT><TT>0<DD>
+LPPROC0</TT><TT> is the command from the
+</TT><TT>LPLIB/process</TT><TT>
 directory to be used to convert input to a format
 that will be accepted by the device.
 The preprocessor is invoked by the spooler.
-<DT><TT>0<DD>
-SPOOLER0</TT> is the command from the
-<TT>LPLIB/spooler</TT>
+<DT></TT><TT>0<DD>
+SPOOLER0</TT><TT> is the command from the
+</TT><TT>LPLIB/spooler</TT><TT>
 directory which will select files using the
-<TT>SCHED</TT>
+</TT><TT>SCHED</TT><TT>
 command and invoke the
-<TT>LPPROC</TT>
+</TT><TT>LPPROC</TT><TT>
 command, putting its output
 into the remote spool directory.
 The output is sent directly to the spool directory on the
 destination machine to avoid conflicts when client and
 server machines share spool directories.
-<DT><TT>0<DD>
-STAT0</TT> is the command from the
-<TT>LPLIB/stat</TT>
+<DT></TT><TT>0<DD>
+STAT0</TT><TT> is the command from the
+</TT><TT>LPLIB/stat</TT><TT>
 directory that prints the status of the device and the list of jobs
 waiting on the queue for the device.
 The status information depends on what is available from the printer
@@ -342,44 +342,44 @@ and interface software.
 The queue information should be changed to show information
 useful in tracking down problems.
 The
-<TT>SCHED</TT>
+</TT><TT>SCHED</TT><TT>
 command is used to show the jobs in the order
 in which they will be printed.
-<DT><TT>0<DD>
-KILL0</TT> is the command from the
-<TT>LPLIB/kill</TT>
+<DT></TT><TT>0<DD>
+KILL0</TT><TT> is the command from the
+</TT><TT>LPLIB/kill</TT><TT>
 that removes jobs from the queue.
 The jobs to be removed are given as arguments to the
-<I>lp</I>
+</TT><I>lp</I><TT>
 command.
 When possible, it should also abort the currently running job
 if it has to be killed.
-<DT><TT>0<DD>
-DAEMON0</TT> is the command from the
-<TT>LPLIB/daemon</TT>
+<DT></TT><TT>0<DD>
+DAEMON0</TT><TT> is the command from the
+</TT><TT>LPLIB/daemon</TT><TT>
 that is meant to run asynchronously to remove
 jobs from the queue.
 Jobs may either be passed on to another host or sent to the
 printing device.
-<I>Lp</I>
+</TT><I>Lp</I><TT>
 always tries to start a daemon process when one is specified.
-<DT><TT>0<DD>
-SCHED0</TT> is the command from the
-<TT>LPLIB/sched</TT>
+<DT></TT><TT>0<DD>
+SCHED0</TT><TT> is the command from the
+</TT><TT>LPLIB/sched</TT><TT>
 that is used to present the job names to the
 daemon and stat programs
 in some order, e.g., first-in-first-out, smallest first.
 </dl>
-<H4>5 Support programs
+</TT><H4>5 Support programs
 </H4>
 <P>
 The following sections describe the basic functions of the programs
 that are found in the subdirectories of
-<TT>$LPLIB</TT>.
+<TT></TT><I>LPLIB</I><TT>.
 The programs in a specific directory vary with the
 type of output device or networks that have to be used.
 </P>
-<H4>5.1 Process directory
+</TT><H4>5.1 Process directory
 </H4>
 <P>
 The
@@ -515,30 +515,30 @@ The daemon first checks to see that it is the only one running
 by using the
 <TT>LOCK</TT>
 program found in the
-<TT>/$cputype/bin/aux</TT>
+<TT>/</TT>cputype/bin/aux<TT>
 directory.
 The
-<TT>LOCK</TT>
+</TT><TT>LOCK</TT><TT>
 command creates a
-<TT>LOCK</TT>
+</TT><TT>LOCK</TT><TT>
 file in the printer's queue directory.
 The daemon then executes the scheduler to obtain the name of the
 next job on the queue.
 </P>
-<P>
+</TT><P>
 The processing of jobs may entail transfer to another host
 or transmission to a printer.
 The details of this are specific to the individual daemons.
 If a job is processed without error, it is removed from the queue.
 If a job does not succeed, the associated files may be
 moved to a printer specific directory in
-<TT>$LPLIB/prob</TT>.
+<TT></TT><I>LPLIB/prob</I><TT>.
 In either case, the daemon can make an entry in the printer's
 log file.
 Before exiting, the daemon should clean up lock files by calling
-<TT>UNLOCK</TT>.
+</TT><TT>UNLOCK</TT><TT>.
 </P>
-<P>
+</TT><P>
 Several non-standard daemon programs have been designed
 to suit various requirements and whims.
 One such program announces job completion and empty paper trays
@@ -557,15 +557,15 @@ The most commonly used scheduler program is
 <TT>FIFO</TT>,
 which looks like this:
 <DL><DT><DD><TT><PRE>
-ls -tr $* | sed -n -e 's/.*  *//' \
-  -e '/^[0-9][0-9]*.[1-9][0-9]*$/p'
+ls -tr * | sed -n -e 's/.*  *//' \
+  -e '/^[0-9][0-9]*.[1-9][0-9]*<I>/p'
 </PRE></TT></DL>
 This lists all the job files in this printer's queue in modification
 time order.
 Jobs entering the queue have a dot (.) prefixed to their name
 to keep the scheduler from selecting them before they are complete.
 </P>
-<H4>6 Where Things Go Wrong
+</I><H4>6 Where Things Go Wrong
 </H4>
 <P>
 There are four directories where
@@ -614,11 +614,11 @@ create the four directories
 and
 <TT>tmp</TT>
 in
-<TT>$LPLIB</TT>
-<TT>(/sys/lib/lp)</TT>
+<TT></TT>LPLIB<TT>
+</TT><TT>(/sys/lib/lp)</TT><TT>
 so that they are writable by anyone.
 </P>
-<H4>6.1 Log directory
+</TT><H4>6.1 Log directory
 </H4>
 <P>
 The log files for a particular
@@ -640,30 +640,30 @@ is written by the program that communicates with the printer itself.
 These are named
 <I>printer</I>.<TT>st</TT>.
 These are overwritten with each new job and are saved in the
-<TT>$LPLIB/prob</TT>
+<TT></TT><I>LPLIB/prob</I><TT>
 directory along with the job under circumstances described below.
 When a printer does not appear to be functioning these files are the
 place to look first.
 </P>
-<H4>6.2 Prob directory
+</TT><H4>6.2 Prob directory
 </H4>
 <P>
 When a job fails to produce output,
 the log files should be checked for any obvious problems.
 If none can be found, a directory with full read and write permissions
 should be created with the name of the printer in the
-<TT>$LPLIB/prob</TT>
+<TT></TT>LPLIB/prob<TT>
 directory.
 Subsequent failure of a job will cause the daemon to leave a
 copy of the job and the printer communication log in
-<TT>$LPLIB/prob/</TT><I>printer</I>
+</TT><TT></TT><I>LPLIB/prob/</I><TT></TT><I>printer</I><TT>
 directory.
 It is common for a printer to enter states from which
 it cannot be rescued except by manually cycling the power on the printer.
 After this is done the print daemon should recover by itself
 (give it a minute).
 If it does not recover, remove the
-<TT>LOCK</TT>
+</TT><TT>LOCK</TT><TT>
 file from the printer's spool directory to kill the daemon.
 The daemon will have to be restarted by sending another job
 to the printer.
@@ -672,7 +672,7 @@ For PostScript printers just use:
 echo '%!PS' | lp
 </PRE></TT></DL>
 </P>
-<H4>6.3 Repairing Stuck Daemons
+</TT><H4>6.3 Repairing Stuck Daemons
 </H4>
 <P>
 There are conditions that occur which are not handled
@@ -703,21 +703,21 @@ The Plan 9
 <TT>lpdaemon</TT>
 will accept jobs sent from BSD LPR/LPD systems.
 The
-<TT>/$cputype/bin/aux/lpdaemon</TT>
+<TT>/</TT>cputype/bin/aux/lpdaemon<TT>
 command is executed from the service call and it accepts print jobs, requests for status,
 and requests to kill jobs.
 The command
-<TT>/$cputype/bin/aux/lpsend</TT>
+</TT><TT>/</TT><I>cputype/bin/aux/lpsend</I><TT>
 is used to send jobs
 to other Plan 9 machines and is usually called from
 within a spooler or daemon script.
 The command
-<TT>/$cputype/bin/aux/lpdsend</TT>
+</TT><TT>/</TT><TT>cputype/bin/aux/lpdsend</TT><TT>
 is used to send jobs
 to machines and printers that use the BSD LPR/LPD protocol and is also usually called from
 within a spooler or daemon script.
 </P>
-<H4>8 Acknowledgements
+</TT><H4>8 Acknowledgements
 </H4>
 <P>
 Special thanks to Rich Drechsler for supplying and maintaining most of
@@ -740,8 +740,7 @@ May, 1986, Berkeley, CA
 [RFC1179] Request for Comments: 1179, Line Printer Daemon Protocol, Aug 1990
 <br>
 [Sys5] System V manual, date unknown
-
 <br>&#32;<br>
 <A href=http://www.lucent.com/copyright.html>
-Copyright</A> &#169; 2000 Lucent Technologies Inc.  All rights reserved.
+Copyright</A> &#169; 2004 Lucent Technologies Inc.  All rights reserved.
 </body></html>

File diff suppressed because it is too large
+ 236 - 236
sys/doc/mk.html


+ 7 - 0
sys/doc/mkfile

@@ -130,6 +130,9 @@ colophon.ps:D:	/sys/lib/man/colophon
 	troff $prereq | lp -dstdout > $target
 	cleanps $target
 
+%.page:D:	%.ps
+	page -w $stem.ps
+
 %.ps:D:	%.ms
 	{ echo $FONTS; cat $stem.ms } | tbl | troff -ms | lp -dstdout > $target
 	cleanps $target
@@ -145,6 +148,10 @@ troff.ps:D:	troff.ms
 	{ echo $FONTS; cat $prereq } | tbl | eqn | troff -ms | lp -dstdout > $target
 	cleanps $target
 
+fossil.ps:D: fossil.ms
+	{ echo $FONTS; cat $prereq } | pic | troff -ms | lp -dstdout >$target
+	cleanps $target
+
 auth.ps:D:	auth.ms
 	{ echo $FONTS; cat $prereq } | pic | tbl | eqn  | troff -ms | lp -dstdout > $target
 	cleanps $target

+ 109 - 110
sys/doc/mkfiles.html

@@ -52,7 +52,7 @@ its source and invoke
 <I>mk</I>
 with the appropriate target as an argument.
 All mkfiles provide the following standard targets:
-<br><img src="data.8940.gif"><br>
+<br><img src="data.19114400.gif"><br>
 <br>&#32;<br>
 If no target is specified on the
 <TT>mk</TT>
@@ -122,13 +122,13 @@ the values of variables, some of which must be
 set by the product mkfile and some of which are
 supplied by the generic mkfile.  Variables in the
 latter class include:
-<br><img src="data.8941.gif"><br>
+<br><img src="data.19114401.gif"><br>
 <br>&#32;<br>
 The following variables are set by the product mkfile
 and used by the generic mkfile.
 Any may be empty depending on the specific product being
 made.
-<br><img src="data.8942.gif"><br>
+<br><img src="data.19114402.gif"><br>
 <H4>Mkfile Organization
 </H4>
 <br>&#32;<br>
@@ -136,20 +136,20 @@ All
 mkfiles
 share the following common structure:
 <DL><DT><DD><TT><PRE>
-&#60;/$objtype/mkfile	# architecture-dependent definitions
+&lt;/<I>objtype/mkfile	# </I>architecture-dependent definitions<I>
 <br>&#32;<br>
-<I>variable definitions</I>		# TARG, OFILES, HFILES, etc.
+</I><I>variable definitions</I><I>		# TARG</I>, <I>OFILES</I>, <I>HFILES</I>, etc.<I>
 <br>&#32;<br>
-&#60;/sys/src/cmd/<I>generic</I>	# mkone, mkmany, mklib, or mksyslib
+&lt;/sys/src/cmd/</I><I>generic</I><I>	# mkone</I>, <I>mkmany</I>, <I>mklib</I>, or <I>mksyslib
 <br>&#32;<br>
-<I>variable overrides</I>		# CFLAGS, objtype, etc.
+</I><I>variable overrides</I><I>		# CFLAGS</I>, <I>objtype</I>, etc.<I>
 <br>&#32;<br>
-<I>extra rules</I>			# overrides, augmented rules, additional targets
+</I><I>extra rules</I><I>			# </I>overrides, augmented rules, additional targets<I>
 </PRE></TT></DL>
 Note that the architecture-dependent mkfiles include file
-<TT>/sys/src/mkfile.proto</TT>
+</I><TT>/sys/src/mkfile.proto</TT><I>
 for system-wide variables that are common to all architectures.
-<br>&#32;<br>
+</I><br>&#32;<br>
 The variables driving the expansion of the generic mkfile
 may be specified in any order as long as they are defined
 before the inclusion of the generic mkfile.  The value
@@ -216,9 +216,9 @@ is executed without a target, the
 <TT>all</TT>
 target is built; it
 produces an executable in
-<TT>$O.out</TT>.
+<TT></TT>O.out<TT>.
 Variable
-<TT>HFILES</TT>
+</TT><TT>HFILES</TT><TT>
 identifies the header files that
 are included in all or most or
 the C source files.  Occasionally,
@@ -228,11 +228,11 @@ source files.  A
 header can be added to the prerequisites for
 those object files by adding a rule of
 the following form following the inclusion of generic mkfile
-<TT>mkone</TT>:
+</TT><TT>mkone</TT><TT>:
 <DL><DT><DD><TT><PRE>
-file.$O:	header.h
+file.</TT><I>O:	header.h
 </PRE></TT></DL>
-<br>&#32;<br>
+</I><br>&#32;<br>
 The mkfile for a directory producing a single
 executable using the normal set of rules is
 trivial: a list of some files followed by the
@@ -242,54 +242,54 @@ For example,
 <TT>/sys/src/cmd/diff/mkfile</TT>
 contains:
 <DL><DT><DD><TT><PRE>
-&#60; /$objtype/mkfile
+&lt; /objtype/mkfile
 
 TARG=diff
 OFILES=\
-	diffdir.$O\
-	diffio.$O\
-	diffreg.$O\
-	main.$O\
+	diffdir.<I>O\
+	diffio.</I>O\
+	diffreg.<I>O\
+	main.</I>O\
 
 HFILES=diff.h
 
-BIN=/$objtype/bin
-&#60;/sys/src/cmd/mkone
+BIN=/<I>objtype/bin
+&lt;/sys/src/cmd/mkone
 </PRE></TT></DL>
 The more complex mkfile in
-<TT>/sys/src/cmd/awk</TT>
+</I><TT>/sys/src/cmd/awk</TT><I>
 overrides compiler and loader variables to
 select the ANSI/POSIX Computing Environment with appropriately
 defined command line variables.  It also overrides
 the default
-<TT>yacc</TT>
+</I><TT>yacc</TT><I>
 rule to place the output soure in file
-<TT>awkgram.c</TT>
+</I><TT>awkgram.c</TT><I>
 and the
-<TT>clean</TT>
+</I><TT>clean</TT><I>
 and
-<TT>nuke</TT>
+</I><TT>nuke</TT><I>
 rules, so it can remove the non-standard intermediate
 files.  Finally, the last three rules build a version of
-<TT>maketab</TT>
+</I><TT>maketab</TT><I>
 appropriate for the architecture where the
-<TT>mk</TT>
+</I><TT>mk</TT><I>
 is being
 run and then executes it to create source file
-<TT>proctab.c</TT>:
+</I><TT>proctab.c</TT><I>:
 <DL><DT><DD><TT><PRE>
-&#60;/$objtype/mkfile
+&lt;/</I>objtype/mkfile
 
 TARG=awk
-OFILES=re.$O\
-	lex.$O\
-	main.$O\
-	parse.$O\
-	proctab.$O\
-	tran.$O\
-	lib.$O\
-	run.$O\
-	awkgram.$O\
+OFILES=re.<I>O\
+	lex.</I>O\
+	main.<I>O\
+	parse.</I>O\
+	proctab.<I>O\
+	tran.</I>O\
+	lib.<I>O\
+	run.</I>O\
+	awkgram.<I>O\
 
 HFILES=awk.h\
 	y.tab.h\
@@ -297,37 +297,37 @@ HFILES=awk.h\
 
 YFILES=awkgram.y
 
-BIN=/$objtype/bin
-&#60;/sys/src/cmd/mkone
+BIN=/</I>objtype/bin
+&lt;/sys/src/cmd/mkone
 CFLAGS=-c -D_REGEXP_EXTENSION -D_RESEARCH_SOURCE \
 	-D_BSD_EXTENSION -DUTF
 YFLAGS=-S -d -v
 CC=pcc
 LD=pcc
-cpuobjtype=`{sed -n 's/^O=//p' /$cputype/mkfile}
+cpuobjtype=`{sed -n 's/^O=//p' /<I>cputype/mkfile}
 
-y.tab.h awkgram.c:	$YFILES
-	$YACC -o awkgram.c $YFLAGS $prereq
+y.tab.h awkgram.c:	</I>YFILES
+	<I>YACC -o awkgram.c </I>YFLAGS <I>prereq
 
 clean:V:
-	rm -f *.[$OS] [$OS].out [$OS].maketab y.tab.? y.debug\
-		 y.output $TARG
+	rm -f *.[</I>OS] [<I>OS].out [</I>OS].maketab y.tab.? y.debug\
+		 y.output <I>TARG
 
 nuke:V:
-	rm -f *.[$OS] [$OS].out [$OS].maketab y.tab.? y.debug\
-		 y.output awkgram.c $TARG
+	rm -f *.[</I>OS] [<I>OS].out [</I>OS].maketab y.tab.? y.debug\
+		 y.output awkgram.c <I>TARG
 
-proctab.c:	$cpuobjtype.maketab
-	./$cpuobjtype.maketab &#62;proctab.c
+proctab.c:	</I>cpuobjtype.maketab
+	./<I>cpuobjtype.maketab &gt;proctab.c
 
-$cpuobjtype.maketab:	y.tab.h maketab.c
-	objtype=$cputype
-	mk maketab.$cputype
+</I>cpuobjtype.maketab:	y.tab.h maketab.c
+	objtype=<I>cputype
+	mk maketab.</I>cputype
 
-maketab.$cputype:V:	y.tab.h maketab.$O
-	$LD -o $O.maketab maketab.$O
+maketab.<I>cputype:V:	y.tab.h maketab.</I>O
+	<I>LD -o </I>O.maketab maketab.<I>O
 </PRE></TT></DL>
-<H4>Mkmany
+</I><H4>Mkmany
 </H4>
 <br>&#32;<br>
 The
@@ -356,45 +356,45 @@ specifies files containing
 common subroutines loaded with all executables.
 Consider the mkfile:
 <DL><DT><DD><TT><PRE>
-&#60;/$objtype/mkfile
+&lt;/objtype/mkfile
 
 TARG=alpha beta
-OFILES=common.$O
-BIN=/$objtype/bin
-&#60;/sys/src/cmd/mkmany
+OFILES=common.<I>O
+BIN=/</I>objtype/bin
+&lt;/sys/src/cmd/mkmany
 </PRE></TT></DL>
 It assumes the main functions for executables
 <TT>alpha</TT>
 and
 <TT>beta</TT>
 are in files
-<TT>alpha.$O</TT>
+<TT>alpha.</TT><I>O</I><TT>
 and
-<TT>beta.$O</TT>
+</TT><TT>beta.</TT><TT>O</TT><TT>
 and that both programs use the subroutines
 in file
-<TT>common.$O</TT>.
+</TT><TT>common.</TT><I>O</I><TT>.
 The
-<TT>all</TT>
+</TT><TT>all</TT><TT>
 target builds all executables, leaving each in
 a file with a name of the form
-<TT>$O.<I>progname</I></TT>
+</TT><TT></TT><TT>O.</TT><I>progname</I><TT></TT><I>
 where
-<I>progname</I>
+</I><I>progname</I><I>
 is the name of the executable.  In this
 example the
-<TT>all</TT>
+</I><TT>all</TT><I>
 target produces executables
-<TT>$O.alpha</TT>
+</I><TT></TT><I>O.alpha</I><TT>
 and 
-<TT>$O.beta</TT>.
-<br>&#32;<br>
+</TT><TT></TT><TT>O.beta</TT><TT>.
+</TT><br>&#32;<br>
 The
 <TT>mkmany</TT>
 rules provide additional
 targets for building a single
 executable:
-<br><img src="data.8943.gif"><br>
+<br><img src="data.19114403.gif"><br>
 <H4>Mklib
 </H4>
 <br>&#32;<br>
@@ -454,30 +454,30 @@ The mkfile from
 <TT>/sys/src/cmd/upas/libString</TT>
 contains the following specifications to
 build the local library
-<TT>libString.a$O</TT>
+<TT>libString.a</TT><I>O</I><TT>
 for the object architecture referenced by
-<TT>$O:</TT>
+</TT><TT></TT><TT>O</TT>:<TT></TT>
 <DL><DT><DD><TT><PRE>
-&#60;/$objtype/mkfile
+&lt;/<I>objtype/mkfile
 
-LIB=libString.a$O
-OFILES=	s_alloc.$O\
-	s_append.$O\
-	s_array.$O\
-	s_copy.$O\
-	s_getline.$O\
-	s_grow.$O\
-	s_nappend.$O\
-	s_parse.$O\
-	s_read.$O\
-	s_read_line.$O\
-	s_tolower.$O\
+LIB=libString.a</I>O
+OFILES=	s_alloc.<I>O\
+	s_append.</I>O\
+	s_array.<I>O\
+	s_copy.</I>O\
+	s_getline.<I>O\
+	s_grow.</I>O\
+	s_nappend.<I>O\
+	s_parse.</I>O\
+	s_read.<I>O\
+	s_read_line.</I>O\
+	s_tolower.<I>O\
 
-&#60;/sys/src/cmd/mklib
+&lt;/sys/src/cmd/mklib
 
 nuke:V:
 	mk clean
-	rm -f libString.a[$OS]
+	rm -f libString.a[</I>OS]
 </PRE></TT></DL>
 The override of the rule for target
 <TT>nuke</TT>
@@ -516,13 +516,13 @@ Special targets support manipulation of a single
 object file; the target
 <TT>objfile</TT>
 updates file
-<TT>objfile<TT>.$O</TT></TT>
+<TT>objfile</TT><TT>.</TT><I>O</I><TT></TT><I>
 in the library of the current architecture and the target
-<TT>objfile.all</TT>
+</I><TT>objfile.all</TT><I>
 updates
-<TT>objfile<TT>.$O</TT></TT>
+</I><TT>objfile</TT><TT>.</TT><TT>O</TT><TT></TT><TT>
 in the libraries of all architectures.
-<H4>Overrides
+</TT><H4>Overrides
 </H4>
 <br>&#32;<br>
 The rules provided by a generic mkfile or
@@ -555,10 +555,10 @@ variables.  Additional constraints can be added
 to a rule by specifying the target and
 the new prerequisite.  For example,
 <DL><DT><DD><TT><PRE>
-%.$O:	header.h
+%.<I>O:	header.h
 </PRE></TT></DL>
 adds file
-<TT>header.h</TT>
+</I><TT>header.h</TT><I>
 the set of prerequisites for all object files.
 There is no mechanism for adding additional
 commands to an existing recipe; if a
@@ -570,37 +570,37 @@ of the original rule exactly.  The recipe
 associated with the new rule
 then replaces the recipe of the original rule.
 For example,
-<TT>/sys/src/cmd/lex/mkfile</TT>
+</I><TT>/sys/src/cmd/lex/mkfile</TT><I>
 overrides the default
-<TT>installall</TT>
+</I><TT>installall</TT><I>
 rule to perform the normal loop on all
 architectures and then copy a prototype file
 to the system library directory.
 <DL><DT><DD><TT><PRE>
-&#60;/$objtype/mkfile
+&lt;/</I>objtype/mkfile
 
 TARG=lex
-OFILES=lmain.$O\
-	y.tab.$O\
-	sub1.$O\
-	sub2.$O\
-	header.$O\
+OFILES=lmain.<I>O\
+	y.tab.</I>O\
+	sub1.<I>O\
+	sub2.</I>O\
+	header.<I>O\
 
 HFILES=ldefs.h\
 
 YFILES=parser.y\
 
-BIN=/$objtype/bin
-&#60;/sys/src/cmd/mkone
+BIN=/</I>objtype/bin
+&lt;/sys/src/cmd/mkone
 
 installall:V:
-	for(objtype in $CPUS)
+	for(objtype in <I>CPUS)
 		mk install
 	cp ncform /sys/lib/lex
 </PRE></TT></DL>
 Another way to perform the same override is to
 add a dependency to the default
-<TT>installall</TT>
+</I><TT>installall</TT><I>
 rule that executes an additional rule to
 install the prototype file:
 <DL><DT><DD><TT><PRE>
@@ -609,7 +609,7 @@ installall:V:	ncform.install
 ncform.install:V:
 	cp ncform /sys/lib/lex
 </PRE></TT></DL>
-<H4>Special Tricks
+</I><H4>Special Tricks
 </H4>
 <br>&#32;<br>
 Two special cases
@@ -660,8 +660,7 @@ augments the default rules to build and install the
 executable with
 elaborate rules to generate
 and maintain the auxiliary spelling lists.
-
 <br>&#32;<br>
 <A href=http://www.lucent.com/copyright.html>
-Copyright</A> &#169; 2000 Lucent Technologies Inc.  All rights reserved.
+Copyright</A> &#169; 2004 Lucent Technologies Inc.  All rights reserved.
 </body></html>

+ 1 - 2
sys/doc/names.html

@@ -689,8 +689,7 @@ London, England,
 <br>
 [Pike91] Pike, R., ``8.5, The Plan 9 Window System'', USENIX Summer
 Conf. Proc., Nashville, 1991
-
 <br>&#32;<br>
 <A href=http://www.lucent.com/copyright.html>
-Copyright</A> &#169; 2000 Lucent Technologies Inc.  All rights reserved.
+Copyright</A> &#169; 2004 Lucent Technologies Inc.  All rights reserved.
 </body></html>

+ 85 - 86
sys/doc/plumb.html

@@ -96,7 +96,7 @@ is by convention the file from which a text editor reads messages requesting it
 open and display a file for editing.
 (See Figure 1.)
 <DL><DT><DD><TT><PRE>
-<br><img src="-.14230.gif"><br>
+<br><img src="-.19117390.gif"><br>
 </PRE></TT></DL>
 <DL>
 <DT><DT>&#32;<DD>
@@ -214,14 +214,14 @@ or
 <TT>image/gif</TT>.
 <DT><DT>&#32;<DD>
 Attributes of the message, given as blank-separated
-<I>name<TT>=</TT>value</I>
+<I>name</I><TT>=</TT><I>value</I><TT>
 pairs.
 The values may be quoted to protect
 blanks or quotes; values may not contain newlines.
 <DT><DT>&#32;<DD>
 The length of the data section, in bytes.
 </dl>
-<br>&#32;<br>
+</TT><br>&#32;<br>
 Here is a sample message, one that (conventionally) tells the editor to open the file
 <TT>/usr/rob/src/mem.c</TT>
 and display line
@@ -330,57 +330,57 @@ to display them; it is analogous to a Windows association rule:
 type is text
 data matches '[a-zA-Z0-9_\-./]+'
 data matches '([a-zA-Z0-9_\-./]+)\.(jpe?g|gif|bit|tiff|ppm)'
-arg isfile $0
+arg isfile <I>0
 plumb to image
 plumb client page -wi
 </PRE></TT></DL>
 (Lines beginning with
-<TT>#</TT>
+</I><TT>#</TT><I>
 are commentary.)
 Consider how this rule handles the following message, annotated down the left column for clarity:
 <DL><DT><DD><TT><PRE>
-<I>src</I>	plumbtest
-<I>dst</I>
-<I>wdir</I>	/usr/rob/pics
-<I>type</I>	text
-<I>attr</I>
-<I>ndata</I>	9
-<I>data</I>	horse.gif
+</I><I>src</I><I>	plumbtest
+</I><I>dst</I><I>
+</I><I>wdir</I><I>	/usr/rob/pics
+</I><I>type</I><I>	text
+</I><I>attr</I><I>
+</I><I>ndata</I><I>	9
+</I><I>data</I><I>	horse.gif
 </PRE></TT></DL>
 The
-<TT>is</TT>
+</I><TT>is</TT><I>
 verb specifies a precise match, and the
-<TT>type</TT>
+</I><TT>type</TT><I>
 field of the message is the string
-<TT>text</TT>,
+</I><TT>text</TT><I>,
 so the first pattern succeeds.
 The
-<TT>matches</TT>
+</I><TT>matches</TT><I>
 verb invokes a regular expression pattern match of the object (here
-<TT>data</TT>)
+</I><TT>data</TT><I>)
 against the argument pattern.
 Both
-<TT>matches</TT>
+</I><TT>matches</TT><I>
 patterns in this rule set will succeed, and in the process set the variables
-<TT>$0</TT>
+</I><TT></TT><I>0</I><TT>
 to the matched string,
-<TT>$1</TT>
+</TT><TT></TT><I>1</I><TT>
 to the first parenthesized submatch, and so on (analogous to
-<TT>&</TT>,
-<TT>1</TT>,
+</TT><TT>&</TT><TT>,
+</TT><TT>\1</TT><TT>,
 etc. in
-<TT>ed</TT>'s
+</TT><TT>ed</TT><TT>'s
 regular expressions).
 The pattern
-<TT>arg</TT>
-<TT>isfile</TT>
-<TT>$0</TT>
+</TT><TT>arg</TT><TT>
+</TT><TT>isfile</TT><TT>
+</TT><TT></TT><TT>0</TT><TT>
 verifies that the named file,
-<TT>horse.gif</TT>,
+</TT><TT>horse.gif</TT><TT>,
 is an actual file in the directory
-<TT>/usr/rob/pics</TT>.
+</TT><TT>/usr/rob/pics</TT><TT>.
 If all the patterns succeed, one of the actions will be executed.
-<br>&#32;<br>
+</TT><br>&#32;<br>
 There are two actions in this rule set.
 The
 <TT>plumb</TT>
@@ -423,13 +423,13 @@ to refine the
 in the message, somewhat in the manner of Structural Regular Expressions [Pike87a].
 For example, consider what happens if the cursor is at the last character of
 <DL><DT><DD><TT><PRE>
-% make nightmare&#62;horse.gif
+% make nightmare&gt;horse.gif
 </PRE></TT></DL>
 and the user asks to plumb what the cursor is pointing at.
 The program creating the plumbing
 message&#173;in this case the terminal emulator running the window&#173;can send the
 entire white-space-delimited string
-<TT>nightmare>horse.gif</TT>
+<TT>nightmare&gt;horse.gif</TT>
 or even the entire line, and the combination of
 <TT>matches</TT>
 rules can determine that the user was referring to the string
@@ -531,29 +531,29 @@ to hold the line number:
 # .h files are looked up in /sys/include and passed to edit
 type is text
 data matches '([a-zA-Z0-9]+\.h)(:([0-9]+))?'
-arg isfile /sys/include/$1
-data set /sys/include/$1
-attr add addr=$3
+arg isfile /sys/include/<I>1
+data set /sys/include/</I>1
+attr add addr=<I>3
 plumb to edit
 </PRE></TT></DL>
 The
-<TT>data</TT>
-<TT>set</TT>
+</I><TT>data</TT><I>
+</I><TT>set</TT><I>
 rule replaces the contents of the data, and the
-<TT>attr</TT>
-<TT>add</TT>
+</I><TT>attr</TT><I>
+</I><TT>add</TT><I>
 rule adds a new attribute to the message.
 The intent of this rule is to permit one to plumb an include file name in a C program
 to trigger the opening of that file, perhaps at a specified line, in the text editor.
 A variant of this rule, discussed below,
 tells the editor how to interpret syntax errors from the compiler,
 or the output of
-<TT>grep</TT>
-<TT>-n</TT>,
+</I><TT>grep</TT><I>
+</I><TT>-n</TT><I>,
 both of which use a fixed syntax
-<I>file<TT>:</TT>line</I>
+</I><I>file</I><TT>:</TT><I>line</I><TT>
 to identify a line of source.
-<br>&#32;<br>
+</TT><br>&#32;<br>
 The Plan 9 text editors interpret the
 <TT>addr</TT>
 attribute as the definition of which portion of the file to display.
@@ -602,29 +602,29 @@ starts the
 <TT>acid</TT>
 debugger [Wint94] in a new window to examine that process:
 <DL><DT><DD><TT><PRE>
-# processes go to acid (assuming strlen(pid) &#62;= 2)
+# processes go to acid (assuming strlen(pid) &gt;= 2)
 type is text
 data matches '[a-zA-Z0-9.:_\-/]+'
 data matches '[0-9][0-9]+'
-arg isdir /proc/$0
-plumb start window acid $0
+arg isdir /proc/0
+plumb start window acid <I>0
 </PRE></TT></DL>
 (Note the use of multiple
-<TT>matches</TT>
+</I><TT>matches</TT><I>
 rules to avoid misfires from strings like
-<TT>party.1999</TT>.)
+</I><TT>party.1999</TT><I>.)
 The
-<TT>arg</TT>
-<TT>isdir</TT>
+</I><TT>arg</TT><I>
+</I><TT>isdir</TT><I>
 rule checks that the pid represents a running process (or broken one; Plan 9 does not create
-<TT>core</TT>
+</I><TT>core</TT><I>
 files but leaves broken processes around for debugging) by checking that the process file
 system has a directory for that pid [Kill84].
 Using this rule, one may plumb the pid string printed by the
-<TT>ps</TT>
+</I><TT>ps</TT><I>
 command or by the operating system when the program breaks;
 the debugger will then start automatically.
-<br>&#32;<br>
+</I><br>&#32;<br>
 The other startup action,
 <TT>plumb</TT>
 <TT>client</TT>,
@@ -650,12 +650,12 @@ Here is the full rule set to pass a regular file to the text editor:
 <DL><DT><DD><TT><PRE>
 # existing files, possibly tagged by address, go to editor
 type is text
-data matches '([.a-zA-Z0-9_/\-]*[a-zA-Z0-9_/\-])('$addr')?'
-arg isfile $1
-data set $1
-attr add addr=$3
+data matches '([.a-zA-Z0-9_/\-]*[a-zA-Z0-9_/\-])('addr')?'
+arg isfile <I>1
+data set </I>1
+attr add addr=<I>3
 plumb to edit
-plumb client window $editor
+plumb client window </I>editor
 </PRE></TT></DL>
 If the editor is already running, the
 <TT>plumb</TT>
@@ -664,17 +664,17 @@ rule causes it to receive the message on the port.
 If not,
 the command
 `<TT>window</TT>
-<TT>$editor</TT>'
+<TT></TT><I>editor</I><TT>'
 will create a new window (using the Plan 9 program
-<TT>window</TT>)
+</TT><TT>window</TT><TT>)
 to run the editor, and once that starts it will open the
-<TT>edit</TT>
+</TT><TT>edit</TT><TT>
 plumbing port as usual and discover this first message already waiting.
-<br>&#32;<br>
+</TT><br>&#32;<br>
 The variables
-<TT>$editor</TT>
+<TT></TT>editor<TT>
 and
-<TT>$addr</TT>
+</TT><TT></TT><I>addr</I><TT>
 in this rule set
 are macros defined in the plumbing rules file; they specify the name of the user's favorite text editor
 and a regular expression
@@ -686,8 +686,8 @@ The macro definitions for Acme and Sam [Pike94,Pike87b] look like this:
 <DL><DT><DD><TT><PRE>
 editor=acme
 # or editor=sam
-addrelem='((#?[0-9]+)|(/[A-Za-z0-9_\^]+/?)|[.$])'
-addr=:($addrelem([,;+\-]$addrelem)*)
+addrelem='((#?[0-9]+)|(/[A-Za-z0-9_\^]+/?)|[.</TT>])'
+addr=:(<I>addrelem([,;+\-]</I>addrelem)*)
 </PRE></TT></DL>
 <br>&#32;<br>
 Finally, the application reads the message from the appropriate port, such as
@@ -748,15 +748,15 @@ to add a new rule set, append to it:
 <DL><DT><DD><TT><PRE>
 % echo 'type is text
 data is self-destruct
-plumb start rm -rf $HOME' &#62;&#62; /mnt/plumb/rules
+plumb start rm -rf <I>HOME' &gt;&gt; /mnt/plumb/rules
 </PRE></TT></DL>
 This rule set will take effect immediately.
 If it has a syntax error, the write will fail with an error message from the plumber,
 such as `malformed rule' or 'undefined verb'.
-<br>&#32;<br>
+</I><br>&#32;<br>
 To restore the plumber to its startup configuration,
 <DL><DT><DD><TT><PRE>
-% cp /usr/$user/lib/plumbing /mnt/plumb/rules
+% cp /usr/user/lib/plumbing /mnt/plumb/rules
 </PRE></TT></DL>
 For more sophisticated changes,
 one can of course use a regular text editor to modify
@@ -878,24 +878,24 @@ program will send another plumbing message, this time to the
 port.
 Here is the rule for that port:
 <DL><DT><DD><TT><PRE>
-# faces -&#62; new mail window for message
+# faces -&gt; new mail window for message
 type is text
 data matches '[a-zA-Z0-9_\-./]+'
 data matches '/mail/fs/[a-zA-Z0-9/]+/[0-9]+'
 plumb to showmail
-plumb start window edmail -s $0
+plumb start window edmail -s <I>0
 </PRE></TT></DL>
 If a program, such as the Acme mail reader, is reading that port, it will open a new window
 in which to display the message.
 If not, the
-<TT>plumb</TT>
-<TT>start</TT>
+</I><TT>plumb</TT><I>
+</I><TT>start</TT><I>
 rule will create a new window and run
-<TT>edmail</TT>,
+</I><TT>edmail</TT><I>,
 a conventional mail reading process, to examine it.
 Notice how the plumbing connects the components of the interface together the same way
 regardless of which components are actually being used to view mail.
-<br>&#32;<br>
+</I><br>&#32;<br>
 There is more to the mail story.
 Naturally, mail boxes in Plan 9 are treated as little file systems, which are synthesized
 on demand by a special-purpose file server that takes a flat mail box file and converts
@@ -918,7 +918,7 @@ To: rob
 
 Check this out.
 
-===&#62; 2/ (image/jpeg) [inline]
+===&gt; 2/ (image/jpeg) [inline]
 	/mail/fs/mbox/25/2/fabio.jpg
 :
 </PRE></TT></DL>
@@ -967,9 +967,9 @@ files and synthesize a plain text file:
 type is text
 data matches '[a-zA-Z0-9_\-./]+'
 data matches '([a-zA-Z0-9_\-./]+)\.doc'
-arg isfile $0
-plumb start doc2txt $data | \
-    plumb -i -d edit -a action=showdata -a filename=$0
+arg isfile 0
+plumb start doc2txt <I>data | \
+    plumb -i -d edit -a action=showdata -a filename=</I>0
 </PRE></TT></DL>
 The arguments to
 <TT>plumb</TT>
@@ -984,13 +984,13 @@ itself rather than interpret it as a file name
 <TT>action=showdata</TT>)
 and provide the original file name
 (<TT>-a</TT>
-<TT>filename=$0</TT>).
+<TT>filename=</TT><I>0</I><TT>).
 Now when a user plumbs a
-<TT>.doc</TT>
+</TT><TT>.doc</TT><TT>
 file the plumbing rules run a process to extract the text and send it as a
 temporary file to the editor for viewing.
 It's imperfect, but it's easy and it beats rebooting.
-<br>&#32;<br>
+</TT><br>&#32;<br>
 Another simple example is a rule that turns man pages into hypertext.
 Manual page entries of the form
 <TT>plumber(1)</TT>
@@ -1001,10 +1001,10 @@ The rule is a little like that for Word documents:
 # man index entries are synthesized
 type is text
 data matches '([a-zA-Z0-9_\-./]+)\(([0-9])\)'
-plumb start man $2 $1 | \
-    plumb -i -d edit -a action=showdata -a filename=/man/$1($2)
+plumb start man 2 <I>1 | \
+    plumb -i -d edit -a action=showdata -a filename=/man/</I>1(<I>2)
 </PRE></TT></DL>
-<br>&#32;<br>
+</I><br>&#32;<br>
 There are many other inventive uses of plumbing.
 One more should give some of the flavor.
 We have a shell script,
@@ -1400,8 +1400,7 @@ Niklaus Wirth and Jurg Gutknecht,
 <I>Project Oberon: The Design of an Operating System and Compilers</I>,
 Addison-Wesley, Reading, 1992.
 
-
 <br>&#32;<br>
 <A href=http://www.lucent.com/copyright.html>
-Copyright</A> &#169; 2000 Lucent Technologies Inc.  All rights reserved.
+Copyright</A> &#169; 2004 Lucent Technologies Inc.  All rights reserved.
 </body></html>

+ 74 - 32
sys/doc/port.html

@@ -191,7 +191,7 @@ some software emulation code in the kernel; to date, this has not been attempted
 <P>
 The PowerPC compiler supports the 32-bit PowerPC architecture only;
 it does not support either the 64-bit extensions or the POWER compatibility instructions.
-It has been used for production operating system work on the 603, 603e, 821, 823, and 860.
+It has been used for production operating system work on the 603, 603e, 604e, 821, 823, and 860.
 On the 8xx floating-point instructions must be emulated.
 Instruction scheduling is not implemented; otherwise the code generated
 is similar to that for the other load-store architectures.
@@ -204,7 +204,8 @@ used by assembly language routines in the libraries.
 </H4>
 <P>
 The ARM compiler is fairly solid; it has been used for some production
-operating system work, although there is no Plan 9 kernel for the machine.
+operating system work including Inferno and the Plan 9 kernel
+for the iPAQ, which uses a StrongArm SA1.
 The compiler supports the ARMv4 architecture;
 it does not support the Thumb instruction set.
 It has been used on ARM7500FE processors and the Strongarm SA1 core machines.
@@ -232,14 +233,14 @@ or directly from a disk created by the
 <TT>format</TT>
 command; see
 <A href="/magic/man2html/8/prep"><I>prep</I>(8).
-</A>Plan 9 runs in 32-bit mode&#173;which requires a 386, 486, or Pentium&#173;and
+</A>Plan 9 runs in 32-bit mode&#173;which requires a 386 or later model x86 processor&#173;and
 has an interrupt-driven I/O system, so it does not
 use the BIOS (except for a small portion of the boot program and floppy boot block).
 This helps performance but limits the set of I/O devices that it can support without
 special code.
 </P>
 <P>
-Plan 9 supports the ISA, EISA, and PCI buses as well as PCMCIA devices.
+Plan 9 supports the ISA, EISA, and PCI buses as well as PCMCIA and PC card devices.
 It is infeasible to list all the supported machines, because
 the PC-clone marketplace is too volatile and there is
 no guarantee that the machine you buy today will contain the
@@ -254,6 +255,7 @@ or the Symbios 53C8XX series.
 Supported Ethernet cards include the
 AMD79C790,
 3COM Etherlink III and 3C589 series,
+Lucent Wavelan and compatibles,
 NE2000,
 WD8003,
 WD8013,
@@ -274,33 +276,36 @@ For more details see
 </A></P>
 <P>
 Over the years,
-Plan 9 has run on a number of VGA cards using the
-S3 80[15],
-S3 928,
-S3 864,
-Tseng ET4000,
-ATI Mach32/64
-and Cirrus Logic CLGD-54[23]x chips.
-However, recent changes to the graphics system have not been
-tested on all these cards; some effort may be needed to get them working again.
-In our lab, most of our machines use the Mach64 chips, so such devices are probably
+Plan 9 has run on a number of VGA cards.
+Recent changes to the graphics system have not been
+tested on most of the older cards; some effort may be needed to get them working again.
+In our lab, most of our machines use the ATI Mach64, S3 ViRGE, or S3 Savage chips,
+so such devices are probably
 the most reliable.
+We also use a few Matrox and TNT cards.
 The system requires a hardware cursor.
 For more details see
 <A href="/magic/man2html/6/vgadb"><I>vgadb</I>(6)
 </A>and
 <A href="/magic/man2html/8/vga"><I>vga</I>(8).
-</A></P>
+</A>The wiki
+(<TT>http://plan9.bell-labs.com/wiki/plan9</TT>)
+contains the definitive list of cards that are known to work; see the ``supported PC hardware''
+page.
+</P>
 <P>
 For audio, Plan 9 supports the Sound Blaster 16 and compatibles.
 (Note that audio doesn't work under Plan 9 with 8-bit Sound Blasters.)
-</P>
+There is also user-level support for USB audio devices; see 
+<A href="/magic/man2html/4/usb"><I>usb</I>(4).
+</A></P>
 <P>
 Finally, it's important to have a three-button mouse with Plan 9.
-The system works with either a PS/2 or serial mouse.
+The system currently works only with mice on the PS/2 port or USB.
+Serial mouse support should return before long.
 </P>
 <P>
-Once you have Plan 9 installed (see the separate installation document)
+Once you have Plan 9 installed (see the wiki's installation document)
 run the program
 <TT>ld</TT>
 from DOS
@@ -335,13 +340,44 @@ See
 <H4>The PowerPC operating system
 </H4>
 <P>
-We have a version of the system that runs on the PowerPC,
-but only on a home-grown machine called Viaduct.
+We have a version of the system that runs on the PowerPC
+on a home-grown machine called Viaduct.
 The Viaduct minibrick is a small (12x9x3 cm) low-cost embedded
 computer consisting of a 50Mhz MPC850, 16MB sdram, 2MB flash,
 and two 10Mb Ethernet ports.  It is designed for home/SOHO
 networking applications such as VPN, firewalls, NAT, etc.
 </P>
+<P>
+The kernel has also been ported to the Motorola MTX embedded motherboard;
+that port is included in the distribution.
+The port only works with a 604e processor (the 603e is substantially different)
+and at present only a single CPU is permitted.
+</P>
+<H4>The Compaq iPAQ operating system
+</H4>
+<P>
+Plan 9 was ported to Compaq's iPAQ Pocket PC,
+which uses the StrongArm SA1 processor.
+The model we have is a 3630; neighboring models also work.
+The kernel can drive a PCMCIA sleeve with a WaveLAN card, but no other PCMCIA
+devices have been ported yet.
+</P>
+<P>
+The iPAQ runs
+<TT>rio</TT>
+with a small keyboard application that allows Palm-style handwriting
+input as well as typing with the stylus on a miniature keyboard.
+</P>
+<P>
+Fco. J. Ballesteros
+(<TT>nemo@plan9.escet.urjc.es</TT>)
+added support for hibernation, but we haven't been able to
+get that to work again in the new kernel; the code is there, however,
+for volunteers to play with.
+See the file
+<TT>/sys/src/9/bitsy/Booting101</TT>
+for information about installing Plan 9 on the iPAQ.
+</P>
 <H4>The file server
 </H4>
 <P>
@@ -361,38 +397,38 @@ to configure a file server.
 <P>
 To boot a file server, follow the directions for booting a CPU server
 using the file name
-<TT>9&lt;I&gt;machtype&lt;/I&gt;fs</TT>
+<TT>9</TT><I>machtype</I><TT>fs</TT><I>
 where
-<I>machtype</I>
+</I><I>machtype</I><I>
 is
-<TT>pc</TT>,
+</I><TT>pc</TT><I>,
 etc. as appropriate.
 We are releasing only the PC version.
 </P>
-<H4>The IBM PC file server
+</I><H4>The IBM PC file server
 </H4>
 <P>
 Except for the restriction to SCSI disks,
 the PC file server has the same hardware requirements as
 the regular PC operating system.
-However, only a subset of the supported SCSI (Adaptec 1542, Buslogic Multimaster,
+However, only a subset of the supported SCSI (Adaptec 1542, Mylex Multimaster,
 and Symbios 53C8XX) and Ethernet (Digital 2114x,
 Intel 8255x, and 3Com) controllers
 may be
 used.
 Any of the boot methods described in
-<A href="/magic/man2html/8/b.com"><I>b.com</I>(8)
+<A href="/magic/man2html/8/9load"><I>9load</I>(8)
 </A>will work.
 </P>
 <P>
 To boot any PC, the file
-<TT>b.com</TT>
-must reside on a MS-DOS formatted floppy, IDE disc,
-or SCSI partition.
+<TT>9load</TT>
+must reside on a MS-DOS formatted floppy, IDE disk,
+or SCSI disk.
 However, PCs have no non-volatile RAM in which the
 file server can store its configuration information, so the system
 stores it in a file on an MS-DOS file system instead.
-This file, however, cannot live on a SCSI disc, only a floppy or IDE.
+This file, however, cannot live on a SCSI disk, only a floppy or IDE.
 (This restriction avoids a lot of duplicated interfaces in the
 system.)
 Thus the file server cannot be all-SCSI.
@@ -442,6 +478,12 @@ it would be possible to use
 </A>to stream them to a SCSI 8mm tape drive.
 <TT>Mkext</TT>
 could then extract them.
+Another alternative is to use
+<I>dump9660</I>
+(see
+<A href="/magic/man2html/8/mk9660"><I>mk9660</I>(8)),
+</A>which stores incremental backups on CD images
+in the form of a dump hierarchy.
 </P>
 <P>
 It is also possible to treat a regular disk, or even a part of a disk,
@@ -451,8 +493,8 @@ learn about the WORM software.
 Again, see
 <A href="/magic/man2html/8/fsconfig"><I>fsconfig</I>(8)
 </A>for details.
-&#191;</P>
+</P>
 <br>&#32;<br>
 <A href=http://www.lucent.com/copyright.html>
-Copyright</A> &#169; 2002 Lucent Technologies Inc.  All rights reserved.
+Copyright</A> &#169; 2004 Lucent Technologies Inc.  All rights reserved.
 </body></html>

+ 16 - 16
sys/doc/prog4.html

@@ -408,13 +408,13 @@ to be created by the
 <TT>mount</TT>
 call, e.g.:
 <DL><DT><DD><TT><PRE>
-% mount $wsys /mnt/wsys 'new -dx 250 -dy 250 -pid 1234'
+% mount <I>wsys /mnt/wsys 'new -dx 250 -dy 250 -pid 1234'
 </PRE></TT></DL>
 In the old system, this sort of control was impossible through the
-<TT>mount</TT>
+</I><TT>mount</TT><I>
 interface.
 </P>
-<P>
+</I><P>
 While we're on the subject of
 <TT>mount</TT>,
 note that with the new security architecture
@@ -425,40 +425,40 @@ note that with the new security architecture
 <A href="/magic/man2html/2/fauth"><I>fauth</I>(2),
 </A><A href="/magic/man2html/5/attach"><I>attach</I>(5),
 </A>and the paper
-<I>Security in Plan 9.)</I>
+<I>Security in Plan 9</I>.)<I>
 The most explicit effect of this change is that
-<TT>mount</TT>
+</I><TT>mount</TT><I>
 now takes another argument,
-<TT>afd</TT>,
+</I><TT>afd</TT><I>,
 a file descriptor for the
 authentication file through which the authentication will be made.
 For most user-level file servers, which do not require authentication, it is
 sufficient to provide
-<TT>-1</TT>
+</I><TT>-1</TT><I>
 as the value of
-<TT>afd:</TT>
+</I><TT>afd:</TT><I>
 <DL><DT><DD><TT><PRE>
 if(mount(fd, -1, "/mnt/wsys", MREPL,
    "new -dx 250 -dy 250 -pid 1234") &lt; 0)
 	error("mount failed: %r");
 </PRE></TT></DL>
 To connect to servers that require authentication, use the new
-<TT>fauth</TT>
+</I><TT>fauth</TT><I>
 system call or the reimplemented
-<TT>amount</TT>
+</I><TT>amount</TT><I>
 (authenticated mount) library call.
 In fact, since
-<TT>amount</TT>
+</I><TT>amount</TT><I>
 handles both authenticating and non-authenticating servers, it is often
 easiest just to replace calls to
-<TT>mount</TT>
+</I><TT>mount</TT><I>
 by calls to
-<TT>amount</TT>;
+</I><TT>amount</TT><I>;
 see
-<A href="/magic/man2html/2/auth"><I>auth</I>(2)
+<A href="/magic/man2html/2/auth"></I><I>auth</I><I>(2)
 </A>for details.
 </P>
-<H4>Print
+</I><H4>Print
 </H4>
 <P>
 The C library has been heavily reworked in places.
@@ -638,5 +638,5 @@ See
 </P>
 <br>&#32;<br>
 <A href=http://www.lucent.com/copyright.html>
-Copyright</A> &#169; 2002 Lucent Technologies Inc.  All rights reserved.
+Copyright</A> &#169; 2004 Lucent Technologies Inc.  All rights reserved.
 </body></html>

File diff suppressed because it is too large
+ 235 - 219
sys/doc/rc.html


+ 32 - 14
sys/doc/release4.html

@@ -8,10 +8,12 @@ data
 Fourth Release Notes
 <br>
 April, 2002
+<br>
+updated June, 2003
 </H1>
 <br>&#32;<br>
 <DL><DT><DD><TT><PRE>
-Copyright &#169; 2002 Lucent Technologies Inc.
+Copyright &#169; 2002-2003 Lucent Technologies Inc.
 All Rights Reserved
 <br>&#32;<br>
 </PRE></TT></DL>
@@ -43,8 +45,12 @@ and many of the other file servers such as
 </A>and
 <A href="/magic/man2html/4/u9fs"><I>u9fs</I>(4)
 </A>work just fine with long names.
-It's only the standard disk-resident file servers
-that don't, and as soon we have versions that do, we'll release them.
+It's only the old disk-resident file servers
+that don't.
+The new file server
+<A href="/magic/man2html/4/fossil"><I>fossil</I>(4)
+</A>handles supports long names and many other features.
+The older servers are now deprecated.
 <br>&#32;<br>
 The following is a partial list of the major changes throughout the system.
 <br>&#32;<br>
@@ -63,7 +69,7 @@ Security has been a focus of attention.
 A new security agent,
 <A href="/magic/man2html/4/factotum"><I>factotum</I>(4),
 </A>manages passwords and other secrets and, coupled with a new secure file store
-<A href="/magic/man2html/4/secstore"><I>secstore</I>(4),
+<A href="/magic/man2html/8/secstore"><I>secstore</I>(8),
 </A>enables secure single sign-on.
 <br>&#32;<br>
 *
@@ -86,17 +92,18 @@ We are phasing out the IL protocol since it doesn't handle long-distance connect
 well (and long-distance networks don't handle it well, either).
 IL is still used by
 <A href="/magic/man2html/4/fs"><I>fs</I>(4)
-</A>(in time, that too will change)
-but TCP has become the standard protocol for all other services.
+</A>but TCP has become the standard protocol for all other services.
 <br>&#32;<br>
 *
 The software for the new network-resident secure block store,
 <A href="/magic/man2html/8/venti"><I>venti</I>(8),
 </A>is included with this distribution.
-We are in the process of reworking
-<A href="/magic/man2html/4/fs"><I>fs</I>(4)
-</A>to use Venti rather than a WORM as its permanent block repository/backup medium,
-but that code is only in the design stage and is not included in this release.
+The new
+file server
+<A href="/magic/man2html/4/fossil"><I>fossil</I>(4)
+</A>uses Venti rather than a WORM as its permanent block repository/backup medium.
+It is still being developed, but is mature enough that a handful of users
+throughout the world are using it as their primary file server.
 <br>&#32;<br>
 *
 The need to handle longer file names triggered a rethinking of the way the
@@ -148,15 +155,26 @@ that they are described in a separate document, entitled
 Changes to the Programming Environment in the Fourth Release of Plan 9.
 Please read it before you start updating your own software to run under the new system.
 <br>&#32;<br>
-There's lots more.
+The installation method has also changed and we're moving towards a new
+method for maintaining updates.
+The Plan 9 Wiki
+(<TT>http://plan9.bell-labs.com/wiki/plan9</TT>)
+and Usenet group
+(<TT>comp.os.plan9</TT>)
+are the places to visit to learn more and stay current.
+In particular, the installation notes are now maintained in the Wiki;
+the traditional papers on installation and start-up are gone.
+<br>&#32;<br>
+There's lots more new stuff.
 If you have problems, mail
 <TT>9trouble@plan9.bell-labs.com</TT>
-or, better, ask the Usenet newsgroup
+or, better, check the wiki
+<TT>http://plan9.bell-labs.com/wiki/plan9</TT>
+or ask the Usenet newsgroup
 <TT>comp.os.plan9</TT>.
-Please don't mail us individually.
 <br>&#32;<br>
 Good Luck!
 <br>&#32;<br>
 <A href=http://www.lucent.com/copyright.html>
-Copyright</A> &#169; 2002 Lucent Technologies Inc.  All rights reserved.
+Copyright</A> &#169; 2004 Lucent Technologies Inc.  All rights reserved.
 </body></html>

File diff suppressed because it is too large
+ 487 - 493
sys/doc/release4.ps


+ 24 - 25
sys/doc/sleep.html

@@ -282,10 +282,10 @@ Our
 <TT>Locks</TT>
 are test-and-set spin locks.
 The routine
-<TT>lock(Lock *l)</TT>
-returns when the current process holds that lock;
-<TT>unlock(Lock *l)</TT>
-releases the lock.
+<TT>lock(Lockr</TT>*l)
+eturns when the current process holds that lock;
+<TT>unlock(Lockr</TT>*l)
+eleases the lock.
 <br>&#32;<br>
 Here is our implementation of
 <TT>sleep</TT>.
@@ -300,13 +300,13 @@ sleep(Rendezvous *r, int (*condition)(void*), void *arg)
 	int s;
 
 	s = inhibit();		/* interrupts */
-	lock(&amp;r-&#62;l);
+	lock(&amp;r-&gt;l);
 
 	/*
 	 * if condition happened, never mind
 	 */
 	if((*condition)(arg)){	
-		unlock(&amp;r-&#62;l);
+		unlock(&amp;r-&gt;l);
 		allow();	/* interrupts */
 		return;
 	}
@@ -315,11 +315,11 @@ sleep(Rendezvous *r, int (*condition)(void*), void *arg)
 	 * now we are committed to
 	 * change state and call scheduler
 	 */
-	if(r-&#62;p)
-		error("double sleep %d %d", r-&#62;p-&#62;pid, thisp-&#62;pid);
-	thisp-&#62;state = Wakeme;
-	r-&#62;p = thisp;
-	unlock(&amp;r-&#62;l);
+	if(r-&gt;p)
+		error("double sleep %d %d", r-&gt;p-&gt;pid, thisp-&gt;pid);
+	thisp-&gt;state = Wakeme;
+	r-&gt;p = thisp;
+	unlock(&amp;r-&gt;l);
 	allow(s);	/* interrupts */
 	sched();	/* relinquish CPU */
 }
@@ -334,15 +334,15 @@ wakeup(Rendezvous *r)
 	int s;
 
 	s = inhibit();	/* interrupts; return old state */
-	lock(&amp;r-&#62;l);
-	p = r-&#62;p;
+	lock(&amp;r-&gt;l);
+	p = r-&gt;p;
 	if(p){
-		r-&#62;p = 0;
-		if(p-&#62;state != Wakeme)
+		r-&gt;p = 0;
+		if(p-&gt;state != Wakeme)
 			panic("wakeup: not Wakeme");
 		ready(p);
 	}
-	unlock(&amp;r-&#62;l);
+	unlock(&amp;r-&gt;l);
 	if(s)
 		allow();
 }
@@ -411,22 +411,22 @@ wakeup(Rendezvous *r)
 	Proc *p;
 	int s;
 
-	p = r-&#62;p;
+	p = r-&gt;p;
 	if(p){
 		s = inhibit();
-		lock(&amp;r-&#62;l);
-		r-&#62;p = 0;
-		if(p-&#62;state != Wakeme)
+		lock(&amp;r-&gt;l);
+		r-&gt;p = 0;
+		if(p-&gt;state != Wakeme)
 			panic("wakeup: not Wakeme");
 		ready(p);
-		unlock(&amp;r-&#62;l);
+		unlock(&amp;r-&gt;l);
 		if(s)
 			allow();
 	}
 }
 </PRE></TT></DL>
 The mistake is that the reading of
-<TT>r->p</TT>
+<TT>r-&gt;p</TT>
 may occur just as the other process calls
 <TT>sleep</TT>,
 so when the interrupt examines the structure it sees no one to wake up,
@@ -434,7 +434,7 @@ and the sleeping process misses its wakeup.
 We wrote the code this way because we reasoned that the fetch
 <TT>p</TT>
 <TT>=</TT>
-<TT>r->p</TT>
+<TT>r-&gt;p</TT>
 was inherently atomic and need not be interlocked.
 The bug was found by examination when a new, very fast device
 was added to the system and sleeps and interrupts were closely overlapped.
@@ -541,8 +541,7 @@ July, 1990.
 MIT,
 Cambridge, Mass.,
 1966.
-
 <br>&#32;<br>
 <A href=http://www.lucent.com/copyright.html>
-Copyright</A> &#169; 2000 Lucent Technologies Inc.  All rights reserved.
+Copyright</A> &#169; 2004 Lucent Technologies Inc.  All rights reserved.
 </body></html>

+ 139 - 139
sys/doc/spin.html

@@ -3,20 +3,21 @@
 
 
 
+<br><img src="-.19126690.gif"><br>
 <title>
 -
 </title>
 <body BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#330088" ALINK="#FF0044">
-<H1>Using SPIN
+<H1>Using <small>SPIN</small>
 </H1>
 <DL><DD><I>Gerard J. Holzmann<br>
 gerard@plan9.bell-labs.com<br>
 </I></DL>
 <DL><DD><H4>ABSTRACT</H4>
-SPIN can be used for proving or disproving logical properties
+<small>SPIN</small> can be used for proving or disproving logical properties
 of concurrent systems.
 To render the proofs, a concurrent system is first
-modeled in a formal specification language called PROMELA.
+modeled in a formal specification language called <small>PROMELA</small>.
 The language allows one to specify the behaviors
 of asynchronously executing
 processes that may interact through synchronous
@@ -29,14 +30,14 @@ of general properties in linear time temporal logic is
 also supported.
 <br>&#32;<br>
 The first part of this manual
-discusses the basic features of the specification language PROMELA.
-The second part describes the verifier SPIN.
+discusses the basic features of the specification language <small>PROMELA</small>.
+The second part describes the verifier <small>SPIN</small>.
 </DL>
-<H4>1 The Language PROMELA
+<H4>1 The Language <small>PROMELA</small>
 </H4>
 <br>&#32;<br>
-PROMELA is short for Protocol Meta Language [Ho91].
-PROMELA is a <I>modeling</I> language, not a programming language.
+<small>PROMELA</small> is short for Protocol Meta Language [Ho91].
+<small>PROMELA</small> is a <I>modeling</I> language, not a programming language.
 A formal model differs in two essential ways from an implementation.
 First, a model is meant to be an abstraction of a design
 that contains only those aspects of the design that are
@@ -48,7 +49,7 @@ system being studied, and a formal statement of relevant correctness
 properties. It is possible to mechanically extract abstract models
 from implementation level code, as discussed, for instance in [HS99].
 <br>&#32;<br>
-Verification with SPIN is often performed in a series of steps,
+Verification with <small>SPIN</small> is often performed in a series of steps,
 with the construction of increasingly detailed models.
 Each model can be verified under different types of
 assumptions about the environment and for different
@@ -66,12 +67,12 @@ Section 1.4 concludes the first part with a discussion of
 special predefined variables and functions that can be used to
 express some correctness properties.
 <br>&#32;<br>
-Up to date manual pages for SPIN can always be found online at:
+Up to date manual pages for <small>SPIN</small> can always be found online at:
 http://cm.bell-labs.com/cm/cs/what/spin/Man/
 <H4>1.1 Basics
 </H4>
 <br>&#32;<br>
-A PROMELA model can contain three different types of objects:
+A <small>PROMELA</small> model can contain three different types of objects:
 <DL>
 <DT><DT>&#32;<DD>
 <DL><DD>
@@ -84,9 +85,9 @@ A PROMELA model can contain three different types of objects:
 </dl>
 <br>&#32;<br>
 All processes are global objects.
-For obvious reasons, a PROMELA model must contain at least one
+For obvious reasons, a <small>PROMELA</small> model must contain at least one
 process to be meaningful.
-Since SPIN is specifically meant to prove properties of
+Since <small>SPIN</small> is specifically meant to prove properties of
 concurrent systems, a model typically contains more than
 one process.
 <br>&#32;<br>
@@ -125,8 +126,8 @@ It behaves the same as the C version.
 Note, finally, that no semicolon follows the single
 <TT>printf</TT>
 statement in the above example.
-In PROMELA, semicolons are used as statement separators,
-not statement terminators.  (The SPIN parser, however, is
+In <small>PROMELA</small>, semicolons are used as statement separators,
+not statement terminators.  (The <small>SPIN</small> parser, however, is
 lenient on this issue.)
 <br>&#32;<br>
 Any process can start new processes by using another
@@ -223,13 +224,13 @@ Within a proctype declaration, statements are separated
 (not terminated) by semicolons.
 As we shall see in examples that follow, instead of the
 semicolon, one can also use the alternative separator
-<TT>-></TT>
+<TT>-&gt;</TT>
 (arrow), wherever that may help to clarify the structure
-of a PROMELA model.
+of a <small>PROMELA</small> model.
 <H4>Semantics of Execution
 </H4>
 <br>&#32;<br>
-In PROMELA there is no difference between a condition or
+In <small>PROMELA</small> there is no difference between a condition or
 expression and a statement.
 Fundamental to the semantics of the language is the
 notion of the <I>executability</I> of statements.
@@ -244,7 +245,7 @@ while (a != b)	/* not valid Promela syntax */
 	skip;	/* wait for a==b */
 ...
 </PRE></TT></DL>
-we achieve the same effect in PROMELA with the statement
+we achieve the same effect in <small>PROMELA</small> with the statement
 <DL><DT><DD><TT><PRE>
 (a == b);
 ...
@@ -253,11 +254,11 @@ Often we indicate that the continuation of an execution
 is conditional on the truth of some expression by using
 the alternate statement separator:
 <DL><DT><DD><TT><PRE>
-(a == b) -&#62; ...
+(a == b) -&gt; ...
 </PRE></TT></DL>
 Assignments and
 <TT>printf</TT>
-statements are always executable in PROMELA.
+statements are always executable in <small>PROMELA</small>.
 A condition, however, can only be executed (passed) when it holds.
 If the condition does not hold, execution blocks until it does.
 There are similar rules for determining the executability
@@ -270,10 +271,10 @@ of the system in which a statement can be executed.
 The effect defines how a statement will alter a
 system state when executed.
 <br>&#32;<br>
-PROMELA assumes that all individual statements are executed
+<small>PROMELA</small> assumes that all individual statements are executed
 atomically: that is, they model the smallest meaningful entities
 of execution in the system being studied.
-This means that PROMELA defines the standard asynchronous interleaving
+This means that <small>PROMELA</small> defines the standard asynchronous interleaving
 model of execution, where a supposed scheduler is free at
 each point in the execution to select any one of the processes
 to proceed by executing a single primitive statement.
@@ -287,7 +288,7 @@ goal has been met, or to demonstrate that the claim is indeed valid.
 <H4>1.1.2 Variables
 </H4>
 <br>&#32;<br>
-The table summarizes the five basic data types used in PROMELA.
+The table summarizes the five basic data types used in <small>PROMELA</small>.
 <TT>Bit</TT>
 and
 <TT>bool</TT>
@@ -302,7 +303,7 @@ is implementation dependent, and corresponds
 to those of the same types in C programs
 that are compiled for the same hardware.
 The values given in the table are most common.
-<br><img src="-.22361.gif"><br>
+<br><img src="-.19126691.gif"><br>
 <br>&#32;<br>
 The following example program declares a array of
 two elements of type
@@ -411,7 +412,7 @@ init {
 }
 </PRE></TT></DL>
 <br>&#32;<br>
-Note that even though PROMELA supports only one-dimensional arrays,
+Note that even though <small>PROMELA</small> supports only one-dimensional arrays,
 a two-dimensional array can be created indirectly with user-defined
 structures, for instance as follows:
 <DL><DT><DD><TT><PRE>
@@ -432,7 +433,7 @@ elements range from 0 to
 <H4>Expressions
 </H4>
 <br>&#32;<br>
-Expressions must be side-effect free in PROMELA.
+Expressions must be side-effect free in <small>PROMELA</small>.
 Specifically, this means that an expression cannot
 contain assignments, or send and receive operations (see section 1.1.3).
 <DL><DT><DD><TT><PRE>
@@ -442,18 +443,18 @@ and
 <DL><DT><DD><TT><PRE>
 c++; c--
 </PRE></TT></DL>
-are assignments in PROMELA, with the same effects.
+are assignments in <small>PROMELA</small>, with the same effects.
 But, unlike in C,
 <DL><DT><DD><TT><PRE>
 b = c++
 </PRE></TT></DL>
 is not a valid assignment, because the right-hand side
-operand is not a valid expression in PROMELA (it is not side-effect free).
+operand is not a valid expression in <small>PROMELA</small> (it is not side-effect free).
 <br>&#32;<br>
 It is also possible to write a side-effect free conditional
 expression, with the following syntax:
 <DL><DT><DD><TT><PRE>
-(expr1 -&#62; expr2 : expr3)
+(expr1 -&gt; expr2 : expr3)
 </PRE></TT></DL>
 The parentheses around the conditional expression are required to
 avoid misinterpretation of the arrow.
@@ -622,12 +623,12 @@ it is not valid to say:
 </PRE></TT></DL>
 or
 <DL><DT><DD><TT><PRE>
-(a &#62; b &amp;&amp; qname!123)
+(a &gt; b &amp;&amp; qname!123)
 </PRE></TT></DL>
 We could rewrite the second example (using an atomic sequence,
 as explained further in section 1.2.1):
 <DL><DT><DD><TT><PRE>
-atomic { (a &#62; b &amp;&amp; !full(qname)) -&#62; qname!123 }
+atomic { (a &gt; b &amp;&amp; !full(qname)) -&gt; qname!123 }
 </PRE></TT></DL>
 The meaning of the first example is ambiguous.  It could mean
 that we want the condition to be true if the receive operation
@@ -641,7 +642,7 @@ to be true when the channel does contain a message with
 value zero.
 We can specify that as follows:
 <DL><DT><DD><TT><PRE>
-atomic { qname?[0] -&#62; qname?var }
+atomic { qname?[0] -&gt; qname?var }
 </PRE></TT></DL>
 The first statement of this atomic sequence is
 an expression without side-effects that
@@ -665,11 +666,11 @@ evaluation of such expressions.
 Note carefully, however, that in non-atomic sequences
 of two statements such as
 <DL><DT><DD><TT><PRE>
-!full(qname) -&#62; qname!msgtype
+!full(qname) -&gt; qname!msgtype
 </PRE></TT></DL>
 and
 <DL><DT><DD><TT><PRE>
-qname?[msgtype] -&#62; qname?msgtype
+qname?[msgtype] -&gt; qname?msgtype
 </PRE></TT></DL>
 the second statement is not necessarily executable
 after the first one has been executed.
@@ -785,21 +786,21 @@ rendezvous handshake.
 As the example shows, symbolic constants can be defined
 with preprocessor macros using
 <TT>#define</TT>.
-The source text of a PROMELA model is translated by the standard
+The source text of a <small>PROMELA</small> model is translated by the standard
 C preprocessor.
 The disadvantage of defining symbolic names in this way is,
-however, that the PROMELA parser will only see the expanded text,
+however, that the <small>PROMELA</small> parser will only see the expanded text,
 and cannot refer to the symbolic names themselves.
-To prevent that, PROMELA also supports another way to define
+To prevent that, <small>PROMELA</small> also supports another way to define
 symbolic names, which are preserved in error reports.
 For instance, by including the declaration
 <DL><DT><DD><TT><PRE>
 mtype = { ack, msg, error, data };
 </PRE></TT></DL>
-at the top of a PROMELA model, the names provided between the
+at the top of a <small>PROMELA</small> model, the names provided between the
 curly braces are equivalent to integers of type
 <TT>byte</TT>,
-but known by their symbolic names to the SPIN parser and the
+but known by their symbolic names to the <small>SPIN</small> parser and the
 verifiers it generates.
 The constant values assigned start at 1, and count up.
 There can be only one
@@ -809,7 +810,7 @@ declaration per model.
 </H4>
 <br>&#32;<br>
 So far, we have seen only some of the basic statements
-of PROMELA, and the way in which they can be combined to
+of <small>PROMELA</small>, and the way in which they can be combined to
 model process behaviors.
 The five types of statements we have mentioned are:
 <TT>printf</TT>,
@@ -825,7 +826,7 @@ is syntactically and semantically equivalent to the
 condition
 <TT>(1)</TT>
 (i.e., to true), and is in fact quietly replaced with this
-expression by the lexical analyzer of SPIN.
+expression by the lexical analyzer of <small>SPIN</small>.
 <br>&#32;<br>
 There are also five types of compound statements.
 <DL>
@@ -918,8 +919,8 @@ sequence
 and an
 <TT>atomic</TT>
 sequence are:
-<DL COMPACT>
-<DT>*<DD>
+<UL>
+<LI>
 A
 <TT>d_step</TT>
 sequence must be completely deterministic.
@@ -927,13 +928,13 @@ sequence must be completely deterministic.
 it is always resolved in a fixed and deterministic
 way: i.e., the first true guard in selection or
 repetition structures is always selected.)
-<DT>*<DD>
+<LI>
 No
 <TT>goto</TT>
 jumps into or out of a
 <TT>d_step</TT>
 sequence are permitted.
-<DT>*<DD>
+<LI>
 The execution of a
 <TT>d_step</TT>
 sequence cannot be interrupted when a
@@ -942,13 +943,13 @@ It is an error if any statement other than
 the first one in a
 <TT>d_step</TT>
 sequence is found to be unexecutable.
-<DT>*<DD>
+<LI>
 A
 <TT>d_step</TT>
 sequence is executed as one single statement.
 In a way, it is a mechanism for adding new types
 of statements to the language.
-</dl>
+</ul>
 <br>&#32;<br>
 None of the items listed above apply to
 <TT>atomic</TT>
@@ -973,8 +974,8 @@ and
 to choose between two options, for instance, we can write:
 <DL><DT><DD><TT><PRE>
 if
-:: (a != b) -&#62; option1
-:: (a == b) -&#62; option2
+:: (a != b) -&gt; option1
+:: (a == b) -&gt; option2
 fi
 </PRE></TT></DL>
 The selection structure above contains two execution sequences,
@@ -1073,7 +1074,7 @@ active proctype counter()
 	do
 	:: count++
 	:: count--
-	:: (count == 0) -&#62; break
+	:: (count == 0) -&gt; break
 	od
 }
 </PRE></TT></DL>
@@ -1093,12 +1094,12 @@ To force termination we could modify the program as follows.
 active proctype counter()
 {
 	do
-	:: (count != 0) -&#62;
+	:: (count != 0) -&gt;
 		if
 		:: count++
 		:: count--
 		fi
-	:: (count == 0) -&#62; break
+	:: (count == 0) -&gt; break
 	od
 }
 </PRE></TT></DL>
@@ -1116,13 +1117,13 @@ We could try to use it in two places in the above example:
 active proctype counter()
 {
 	do
-	:: (count != 0) -&#62;
+	:: (count != 0) -&gt;
 		if
 		:: count++
 		:: count--
 		:: else
 		fi
-	:: else -&#62; break
+	:: else -&gt; break
 	od
 }
 </PRE></TT></DL>
@@ -1152,9 +1153,9 @@ of two non-zero, positive numbers:
 proctype Euclid(int x, y)
 {
 	do
-	:: (x &#62;  y) -&#62; x = x - y
-	:: (x &#60;  y) -&#62; y = y - x
-	:: (x == y) -&#62; goto done
+	:: (x &gt;  y) -&gt; x = x - y
+	:: (x &lt;  y) -&gt; y = y - x
+	:: (x == y) -&gt; goto done
 	od;
 done:
 	skip
@@ -1192,9 +1193,9 @@ active proctype Dijkstra()
 {	byte count = 1;
 
 	do
-	:: (count == 1) -&#62;
+	:: (count == 1) -&gt;
 		sema!p; count = 0
-	:: (count == 0) -&#62;
+	:: (count == 0) -&gt;
 		sema?v; count = 1
 	od	
 }
@@ -1214,7 +1215,7 @@ can enter its critical section at a time.
 It does not necessarily prevent the monopolization of
 the access to the critical section by one of the processes.
 <br>&#32;<br>
-PROMELA does not have a mechanism for defining functions or
+<small>PROMELA</small> does not have a mechanism for defining functions or
 procedures.  Where necessary, though, these may be
 modeled with the help of additional processes.
 The return value of a function, for instance, can be passed
@@ -1228,8 +1229,8 @@ proctype fact(int n; chan p)
 	int result;
 
 	if
-	:: (n &#60;= 1) -&#62; p!1
-	:: (n &#62;= 2) -&#62;
+	:: (n &lt;= 1) -&gt; p!1
+	:: (n &gt;= 2) -&gt;
 		run fact(n-1, child);
 		child?result;
 		p!n*result
@@ -1248,7 +1249,7 @@ init
 </PRE></TT></DL>
 Each process creates a private channel and uses it
 to communicate with its direct descendant.
-There are no input statements in PROMELA.
+There are no input statements in <small>PROMELA</small>.
 The reason is that models must always be complete to
 allow for logical verifications, and input statements
 would leave at least the source of some information unspecified.
@@ -1275,7 +1276,7 @@ potential deadlock state.
 The
 <TT>timeout</TT>
 takes no parameters, because the types of properties we
-would like to prove for PROMELA models must be proven independent
+would like to prove for <small>PROMELA</small> models must be proven independent
 of all absolute and relative timing considerations.
 In particular, the relative speeds of processes can never be
 known with certainty in an asynchronous system.
@@ -1293,7 +1294,7 @@ where the letters
 <TT>P</TT>
 and
 <TT>E</TT>
-represent arbitrary PROMELA fragments.
+represent arbitrary <small>PROMELA</small> fragments.
 Execution of the
 <TT>unless</TT>
 statement begins with the execution of statements from
@@ -1302,7 +1303,7 @@ Before each statement execution in
 <TT>P</TT>
 the executability of the first statement of
 <TT>E</TT>
-is checked, using the normal PROMELA semantics of executability.
+is checked, using the normal <small>PROMELA</small> semantics of executability.
 Execution of statements from
 <TT>P</TT>
 proceeds only while the first statement of
@@ -1330,11 +1331,11 @@ An example of the use of escape sequences is:
 <DL><DT><DD><TT><PRE>
 A;
 do
-:: b1 -&#62; B1
-:: b2 -&#62; B2
+:: b1 -&gt; B1
+:: b2 -&gt; B2
 ...
 od
-unless { c -&#62; C };
+unless { c -&gt; C };
 D
 </PRE></TT></DL>
 As shown in the example, the curly braces around the main sequence
@@ -1347,10 +1348,10 @@ Note that this is not necessarily equivalent to the construct
 <DL><DT><DD><TT><PRE>
 A;
 do
-:: b1 -&#62; B1
-:: b2 -&#62; B2
+:: b1 -&gt; B1
+:: b2 -&gt; B2
 ...
-:: c -&#62; break
+:: c -&gt; break
 od;
 C; D
 </PRE></TT></DL>
@@ -1366,7 +1367,7 @@ start of the option sequences.
 <H4>1.3 Correctness Properties
 </H4>
 <br>&#32;<br>
-There are three ways to express correctness properties in PROMELA,
+There are three ways to express correctness properties in <small>PROMELA</small>,
 using:
 <DL>
 <DT><DT>&#32;<DD>
@@ -1402,7 +1403,7 @@ A failing assertion will cause execution to be aborted.
 <H4>1.3.2 Special Labels
 </H4>
 <br>&#32;<br>
-Labels in a PROMELA specification ordinarily serve as
+Labels in a <small>PROMELA</small> specification ordinarily serve as
 targets for unconditional
 <TT>goto</TT>
 jumps, as usual.
@@ -1412,13 +1413,13 @@ We discuss them in the next three subsections.
 <H4>1.3.2.1 End-State Labels
 </H4>
 <br>&#32;<br>
-When a PROMELA model is checked for reachable deadlock states
+When a <small>PROMELA</small> model is checked for reachable deadlock states
 by the verifier, it must be able to distinguish valid <I>end state</I>s
 from invalid ones.
 By default, the only valid end states are those in which
-every PROMELA process that was instantiated has reached the end of
+every <small>PROMELA</small> process that was instantiated has reached the end of
 its code.
-Not all PROMELA processes, however, are meant to reach the
+Not all <small>PROMELA</small> processes, however, are meant to reach the
 end of their code.
 Some may very well linger in a known wait
 state, or they may sit patiently in a loop
@@ -1434,9 +1435,9 @@ proctype Dijkstra()
 {	byte count = 1;
 
 end:	do
-	:: (count == 1) -&#62;
+	:: (count == 1) -&gt;
 		sema!p; count = 0
-	:: (count == 0) -&#62;
+	:: (count == 0) -&gt;
 		sema?v; count = 1
 	od	
 }
@@ -1449,7 +1450,7 @@ has not reached its closing curly brace, but waits at the label.
 Of course, such a state could still be part of a deadlock state, but
 if so, it is not caused by this particular process.
 <br>&#32;<br>
-There may be more than one end-state label per PROMELA model.
+There may be more than one end-state label per <small>PROMELA</small> model.
 If so, all labels that occur within the same process body must
 be unique.
 The rule is that every label name with the prefix
@@ -1458,7 +1459,7 @@ is taken to be an end-state label.
 <H4>1.3.2.2 Progress-State Labels
 </H4>
 <br>&#32;<br>
-In the same spirit, PROMELA also allows for the definition of
+In the same spirit, <small>PROMELA</small> also allows for the definition of
 <TT>progress</TT>
 labels.
 Passing a progress label during an execution is interpreted
@@ -1480,9 +1481,9 @@ proctype Dijkstra()
 {	byte count = 1;
 
 end:	do
-	:: (count == 1) -&#62;
+	:: (count == 1) -&gt;
 progress:	sema!p; count = 0
-	:: (count == 0) -&#62;
+	:: (count == 0) -&gt;
 		sema?v; count = 1
 	od	
 }
@@ -1530,7 +1531,7 @@ active proctype monitor()
 {
 progress:
 	do
-	:: P -&#62; Q
+	:: P -&gt; Q
 	od
 }
 </PRE></TT></DL>
@@ -1544,13 +1545,13 @@ active proctype monitor()
 {
 progress:
 	do
-	:: P -&#62; assert(P || Q)
+	:: P -&gt; assert(P || Q)
 	od
 }
 </PRE></TT></DL>
 but this does not quite do the job.
 Note that we cannot make any assumptions about the
-relative execution speeds of processes in a PROMELA model.
+relative execution speeds of processes in a <small>PROMELA</small> model.
 This means that if in the remainder of the system the
 property
 <TT>P</TT>
@@ -1581,7 +1582,7 @@ to express these important types of liveness properties.
 A general way to express system properties of the type we
 have just discussed is to use linear time temporal logic (LTL)
 formulae.
-Every PROMELA expression is automatically also a valid LTL formula.
+Every <small>PROMELA</small> expression is automatically also a valid LTL formula.
 An LTL formula can also contain the unary temporal operators &#164;
 (pronounced always), &#186; (pronounced eventually), and
 two binary temporal operators
@@ -1590,7 +1591,7 @@ two binary temporal operators
 <B><I>U</I></B>
 (pronounced strong until).
 <br>&#32;<br>
-Where the value of a PROMELA expression without temporal operators can be
+Where the value of a <small>PROMELA</small> expression without temporal operators can be
 defined uniquely for individual system states, without further context,
 the truth value of an LTL formula is defined for sequences of states:
 specifically, it is defined for the first state of a given infinite
@@ -1605,7 +1606,7 @@ with
 <TT>p</TT>
 and
 <TT>q</TT>
-standard PROMELA expressions, is true for
+standard <small>PROMELA</small> expressions, is true for
 <TT>s0</TT>
 either if
 <TT>q</TT>
@@ -1658,28 +1659,28 @@ is true eventually leads to a system state in which property
 is true,''
 we can write the LTL formula:
 <DL><DT><DD><TT><PRE>
-&#164; (P -&#62; &#186; Q)
+&#164; (P -&gt; &#186; Q)
 </PRE></TT></DL>
 where the logical implication symbol
-<TT>-></TT>
+<TT>-&gt;</TT>
 is defined in the usual way as
 <DL><DT><DD><TT><PRE>
-P =&#62; Q means !P || Q
+P =&gt; Q means !P || Q
 </PRE></TT></DL>
 <H4>Mapping LTL Formulae onto Never Claims
 </H4>
 <br>&#32;<br>
-PROMELA does not include syntax for specifying LTL formulae
+<small>PROMELA</small> does not include syntax for specifying LTL formulae
 directly, but it relies on the fact that every such
 formula can be translated into a special type of
 automaton, known as a B&uuml;chi automaton.
-In the syntax of PROMELA this automaton is called a
+In the syntax of <small>PROMELA</small> this automaton is called a
 <TT>never</TT>
 claim.
 If you don't care too much about the details of
 <TT>never</TT>
 claims, you can skip the remainder of this section and
-simple remember that SPIN can convert any LTL formula
+simple remember that <small>SPIN</small> can convert any LTL formula
 automatically into the proper never claim syntax with
 the command:
 <DL><DT><DD><TT><PRE>
@@ -1692,7 +1693,7 @@ never {
 	...
 }
 </PRE></TT></DL>
-where the dots can contain any PROMELA fragment, including
+where the dots can contain any <small>PROMELA</small> fragment, including
 arbitrary repetition, selection, unless constructs,
 jumps, etc.
 <br>&#32;<br>
@@ -1746,7 +1747,7 @@ must exist, at least one of which is labeled with an
 <TT>accept</TT>
 label (inside the never claim).
 <br>&#32;<br>
-Since PROMELA models can also express terminating system behaviors,
+Since <small>PROMELA</small> models can also express terminating system behaviors,
 we have to define the semantics of the
 <TT>never</TT>
 claims also for those behaviors.
@@ -1788,9 +1789,9 @@ section.
 <br>&#32;<br>
 The difference between a
 <TT>never</TT>
-claim and the remainder of a PROMELA system can be explained
+claim and the remainder of a <small>PROMELA</small> system can be explained
 as follows.
-A PROMELA model defines an asynchronous interleaving product of the
+A <small>PROMELA</small> model defines an asynchronous interleaving product of the
 behaviors of individual processes.
 Given an arbitrary system state, its successor states are
 conceptually obtained in two steps.
@@ -1828,7 +1829,7 @@ of the system (the first half of the state pair).
 <br>&#32;<br>
 To manually translate an LTL formula into a
 <TT>never</TT>
-claim (e.g. foregoing the builtin translation that SPIN
+claim (e.g. foregoing the builtin translation that <small>SPIN</small>
 offers), we must carefully consider whether the
 formula expresses a positive or a negative property.
 A positive property expresses a good behavior that we
@@ -1849,7 +1850,7 @@ Suppose that the LTL formula &#186;&#164;
 <TT>p</TT>,
 with
 <TT>p</TT>
-a PROMELA expression, expresses a negative claim
+a <small>PROMELA</small> expression, expresses a negative claim
 (i.e., it is considered a correctness violation if
 there exists any execution sequence in which
 <TT>p</TT>
@@ -1858,10 +1859,10 @@ This can be written in a
 <TT>never</TT>
 claim as:
 <DL><DT><DD><TT><PRE>
-never {	/* &#60;&#62;[]p */
+never {	/* &lt;&gt;[]p */
 	do
 	:: skip	/* after an arbitrarily long prefix */
-	:: p -&#62; break	/* p becomes true */
+	:: p -&gt; break	/* p becomes true */
 	od;
 accept:	do
 	:: p	/* and remains true forever after */
@@ -1883,10 +1884,10 @@ The requirement now says that it is a violation if
 <TT>p</TT>
 does not hold infinitely long.
 <DL><DT><DD><TT><PRE>
-never {	/* &#60;&#62;!p*/
+never {	/* &lt;&gt;!p*/
 	do
 	:: skip
-	:: !p -&#62; break
+	:: !p -&gt; break
 	od
 }
 </PRE></TT></DL>
@@ -1895,10 +1896,10 @@ closing terminating brace.
 Since the first violation of the property suffices to disprove
 it, we could also have written:
 <DL><DT><DD><TT><PRE>
-never {	/* &#60;&#62;!p*/
+never {	/* &lt;&gt;!p*/
 	do
 	:: p
-	:: !p -&#62; break
+	:: !p -&gt; break
 	od
 }
 </PRE></TT></DL>
@@ -1910,7 +1911,7 @@ never { do :: assert(p) od }
 Suppose we wish to express that it is a violation of our
 correctness requirements if there exists any execution in
 the system where
-<TT>&#164; (p -> &#186; q)</TT>
+<TT>&#164; (p -&gt; &#186; q)</TT>
 is violated (i.e., the negation of this formula is satisfied).
 The following
 <TT>never</TT>
@@ -1919,7 +1920,7 @@ claim expresses that property:
 never {
 	do
 	:: skip
-	:: p &amp;&amp; !q -&#62; break
+	:: p &amp;&amp; !q -&gt; break
 	od;
 accept:
 	do
@@ -1940,18 +1941,18 @@ is false.
 The above formalization checks for all occurrences, anywhere in a trace.
 <br>&#32;<br>
 Finally, consider a formalization of the LTL property
-<TT>&#164; (p -> (q U r))</TT>.
+<TT>&#164; (p -&gt; (q U r))</TT>.
 The corresponding claim is:
 <DL><DT><DD><TT><PRE>
 never {
 	do
 	:: skip		/* to match any occurrence */
-	:: p &amp;&amp;  q &amp;&amp; !r -&#62; break
-	:: p &amp;&amp; !q &amp;&amp; !r -&#62; goto error
+	:: p &amp;&amp;  q &amp;&amp; !r -&gt; break
+	:: p &amp;&amp; !q &amp;&amp; !r -&gt; goto error
 	od;
 	do
 	::  q &amp;&amp; !r
-	:: !q &amp;&amp; !r -&#62; break
+	:: !q &amp;&amp; !r -&gt; break
 	od;
 error:	skip
 }
@@ -1995,7 +1996,7 @@ never {
 	 */
 accept:
 	do
-	:: _last != 1 -&#62; _last == 1
+	:: _last != 1 -&gt; _last == 1
 	od
 }
 </PRE></TT></DL>
@@ -2025,7 +2026,7 @@ never {
 	 * state as process 2, or one with smaller value.
 	 */
 accept:	do
-	:: pc_value(1) &#60;= pc_value(2)
+	:: pc_value(1) &lt;= pc_value(2)
 	od
 }
 </PRE></TT></DL>
@@ -2057,12 +2058,12 @@ in
 <TT>proctype procname</TT>.
 It is an error if the process referred to is not an instantiation
 of that proctype.
-<H4>2 Verifications with SPIN
+<H4>2 Verifications with <small>SPIN</small>
 </H4>
 <br>&#32;<br>
-The easiest way to use SPIN is probably on a Windows terminal
-with the Tcl/Tk implementation of XSPIN.
-All functionality of SPIN, however, is accessible from
+The easiest way to use <small>SPIN</small> is probably on a Windows terminal
+with the Tcl/Tk implementation of <small>XSPIN</small>.
+All functionality of <small>SPIN</small>, however, is accessible from
 any plain ASCII terminal, and there is something to be
 said for directly interacting with the tool itself.
 <br>&#32;<br>
@@ -2071,7 +2072,7 @@ a common mode of operation in using the verifier.
 A more tutorial style description of the verification
 process can be found in [Ho93].
 More detail on the verification of large systems with the
-help of SPIN's supertrace (bitstate) verification algorithm
+help of <small>SPIN</small>'s supertrace (bitstate) verification algorithm
 can be found in [Ho95].
 <DL>
 <DT><DT>&#32;<DD>
@@ -2100,14 +2101,14 @@ Exploiting partial order reductions (section 2.6).
 <H4>2.1 Random and Interactive Simulations
 </H4>
 <br>&#32;<br>
-Given a model in PROMELA, say stored in a file called
+Given a model in <small>PROMELA</small>, say stored in a file called
 <TT>spec</TT>,
 the easiest mode of operation is to perform a random simulation.
 For instance,
 <DL><DT><DD><TT><PRE>
 spin -p spec
 </PRE></TT></DL>
-tells SPIN to perform a random simulation, while printing the
+tells <small>SPIN</small> to perform a random simulation, while printing the
 process moves selected for execution at each step (by default
 nothing is printed, other than explicit
 <TT>printf</TT>
@@ -2123,7 +2124,7 @@ or receive statements (add option
 <TT>-r</TT>).
 Use option
 <TT>-n</TT>N
-(with N any number) to fix the seed on SPIN's internal
+(with N any number) to fix the seed on <small>SPIN</small>'s internal
 random number generator, and thus make the simulation runs
 reproducible.
 By default the current time is used to seed the random number
@@ -2172,7 +2173,7 @@ pcc -o pan pan.c		# standard exhaustive search
 </PRE></TT></DL>
 If you know a memory bound that you want to restrict the run to
 (e.g., to avoid paging), find the nearest power of 2 (e.g., 23
-for the bound 2^23 bytes) and compile as follows.
+for the bound 2^&lt;small&gt;&lt;small&gt;&lt;small&gt;23&lt;/small&gt;&lt;/small&gt;&lt;/small&gt;&lt;big&gt;&lt;big&gt;&lt;big&gt; bytes) and compile as follows.
 <DL><DT><DD><TT><PRE>
 pcc '-DMEMCNT=23' -o pan pan.c
 </PRE></TT></DL>
@@ -2203,26 +2204,26 @@ for peak performance should be.
 </H4>
 <br>&#32;<br>
 For a standard exhaustive run, you can override the default choice
-for the size for the hash table (2^18 slots) with option
+for the size for the hash table (2^&lt;/big&gt;&lt;/big&gt;&lt;/big&gt;&lt;small&gt;&lt;small&gt;&lt;small&gt;18&lt;/small&gt;&lt;/small&gt;&lt;/small&gt;&lt;big&gt;&lt;big&gt;&lt;big&gt; slots) with option
 <TT>-w</TT>.
 For instance,
 <DL><DT><DD><TT><PRE>
 pan -w23
 </PRE></TT></DL>
-selects 2^23 slots.
+selects 2^&lt;/big&gt;&lt;/big&gt;&lt;/big&gt;&lt;small&gt;&lt;small&gt;&lt;small&gt;23&lt;/small&gt;&lt;/small&gt;&lt;/small&gt;&lt;big&gt;&lt;big&gt;&lt;big&gt; slots.
 The hash table size should optimally be roughly equal to the number of
 reachable states you expect (within say a factor of two or three).
 Too large a number merely wastes memory, too low a number wastes
 CPU time, but neither can affect the correctness of the result.
 <br>&#32;<br>
 For a supertrace run, the hash table <I>is</I> the memory arena, and
-you can override the default of 2^22 bits with any other number.
+you can override the default of 2^&lt;/big&gt;&lt;/big&gt;&lt;/big&gt;&lt;small&gt;&lt;small&gt;&lt;small&gt;22&lt;/small&gt;&lt;/small&gt;&lt;/small&gt;&lt;big&gt;&lt;big&gt;&lt;big&gt; bits with any other number.
 Set it to the maximum size of physical memory you can grab without
 making the system page, again within a factor of say two or three.
 Use, for instance
 <TT>-w23</TT>
 if you expect 8 million reachable states and have access to at least
-8 million (2^23) bits of memory (i.e., 2^20 or 1 Megabyte of RAM).
+8 million (2^&lt;/big&gt;&lt;/big&gt;&lt;/big&gt;&lt;small&gt;&lt;small&gt;&lt;small&gt;23&lt;/small&gt;&lt;/small&gt;&lt;/small&gt;&lt;big&gt;&lt;big&gt;&lt;big&gt;) bits of memory (i.e., 2^&lt;/big&gt;&lt;/big&gt;&lt;/big&gt;&lt;small&gt;&lt;small&gt;&lt;small&gt;20&lt;/small&gt;&lt;/small&gt;&lt;/small&gt;&lt;big&gt;&lt;big&gt;&lt;big&gt; or 1 Megabyte of RAM).
 <H4>2.4.2 Search Depth
 </H4>
 <br>&#32;<br>
@@ -2330,11 +2331,11 @@ pan --
 </H4>
 <br>&#32;<br>
 If the verification run reports an error,
-any error, SPIN dumps an error trail into a file named
+any error, </big></big></big><small>SPIN</small> dumps an error trail into a file named
 <TT>spec.trail</TT>,
 where
 <TT>spec</TT>
-is the name of your original PROMELA file.
+is the name of your original <small>PROMELA</small> file.
 To inspect the trail, and determine the cause of the error,
 you must use the guided simulation option.
 For instance:
@@ -2374,9 +2375,9 @@ pan -c0
 <H4>State Assignments
 </H4>
 <br>&#32;<br>
-Internally, the verifiers produced by SPIN deal with a formalization of
-a PROMELA model in terms of extended finite state machines.
-SPIN therefore assigns state numbers to all statements in the model.
+Internally, the verifiers produced by <small>SPIN</small> deal with a formalization of
+a <small>PROMELA</small> model in terms of extended finite state machines.
+<small>SPIN</small> therefore assigns state numbers to all statements in the model.
 The state numbers are listed in all the relevant output to make it
 completely unambiguous (source line references unfortunately do not
 have that property).
@@ -2391,7 +2392,7 @@ in the model.
 <H4>2.6 Exploiting Partial Order Reductions
 </H4>
 <br>&#32;<br>
-The search algorithm used by SPIN is optimized
+The search algorithm used by <small>SPIN</small> is optimized
 according to the rules of a partial order theory explained in [HoPe94].
 The effect of the reduction, however, can be increased considerably if the verifier
 has extra information about the access of processes to global
@@ -2450,10 +2451,10 @@ found in [HoPe94].
 <br>&#32;<br>
 For reference, the following table contains all the keywords,
 predefined functions, predefined variables, and
-special label-prefixes of the language PROMELA,
+special label-prefixes of the language <small>PROMELA</small>,
 and refers to the section of this paper in
 which they were discussed.
-<br><img src="-.22362.gif"><br>
+<br><img src="-.19126692.gif"><br>
 <H4>References
 </H4>
 <br>&#32;<br>
@@ -2483,8 +2484,7 @@ verification models from source code,''
 Proc. Formal Methods in Software Engineering and Distributed
 Systems,
 PSTV/FORTE99, Beijng, China, Oct. 1999, Kluwer,pp. 481-497.
-
 <br>&#32;<br>
 <A href=http://www.lucent.com/copyright.html>
-Copyright</A> &#169; 2000 Lucent Technologies Inc.  All rights reserved.
+Copyright</A> &#169; 2004 Lucent Technologies Inc.  All rights reserved.
 </body></html>

+ 1 - 1
sys/doc/troff.ps

@@ -3338,7 +3338,7 @@ cleartomark
 
 /Dl {
 	inpath
-		{pop pop neg lineto}
+		{neg lineto pop pop}
 		{newpath neg moveto neg lineto stroke}
 	ifelse
 } bind def

+ 20 - 21
sys/doc/utf.html

@@ -7,11 +7,11 @@ data
 <br>
 or
 <br>
-&#191;ALPHA&#191;&#191;MU&#191;&#191;ALPHA &#191;&#191;&#191;MUEPSILON
+&#922;&#945;&#955;&#951;&#956;&#941;&#961;&#945; &#954;&#972;&#963;&#956;&#949;
 <br>
 or
 <br>
-&#191;&#191;&#191;&#191;&#191; &#191;&#191;
+&#12371;&#12435;&#12395;&#12385;&#12399; &#19990;&#30028;
 </H1>
 <DL><DD><I>Rob Pike<br>
 Ken Thompson<br>
@@ -268,7 +268,7 @@ daily in our work.  We no longer test our imaginations
 to find ways to include non-ASCII symbols in our text;
 why type
 <TT>:-)</TT>
-when you can use the character &#191;?
+when you can use the character &#9786;?
 Most compelling is the ability to absorb documents
 and data that contain non-ASCII characters; our browser for the
 Oxford English Dictionary
@@ -312,7 +312,7 @@ The Plan 9 compiler extends ANSI C to treat any Unicode
 character with a value outside of the ASCII range as
 an alphabetic.
 To a Greek programmer or an English mathematician,
-ALPHA is a sensible and now valid variable name.
+&#945; is a sensible and now valid variable name.
 </P>
 <P>
 On the semantic level, ANSI C allows,
@@ -341,13 +341,13 @@ L'x'	is 120
 'x'	is 120
 L'&yuml;'	is 255
 '&yuml;'	is -1, stdio EOF (if char is signed)
-L'ALPHA'	is 945
-'ALPHA'	is illegal
+L'&#945;'	is 945
+'&#945;'	is illegal
 </PRE></TT></DL>
 In the string constants,
 <DL><DT><DD><TT><PRE>
-"&#191;&#191;&#191;&#191;&#191; &#191;&#191;"
-L"&#191;&#191;&#191;&#191;&#191; &#191;&#191;",
+"&#12371;&#12435;&#12395;&#12385;&#12399; &#19990;&#30028;"
+L"&#12371;&#12435;&#12395;&#12385;&#12399; &#19990;&#30028;",
 </PRE></TT></DL>
 the former is an array of
 <TT>chars</TT>
@@ -386,7 +386,7 @@ printed under
 <TT>%c</TT>
 will be identical,
 but
-<TT>L'ALPHA'</TT>
+<TT>L'</TT>&#945;<TT>'</TT>
 will print as the Unicode
 character with decimal value 177.
 The character conversion
@@ -396,7 +396,7 @@ to 16 bits before converting to UTF.
 Thus
 <TT>L'&yuml;'</TT>
 and
-<TT>L'ALPHA'</TT>
+<TT>L'</TT>&#945;<TT>'</TT>
 will print correctly under
 <TT>%C</TT>,
 but
@@ -435,10 +435,10 @@ These programs must be found and corrected.
 <P>
 Here is a complete example:
 <DL><DT><DD><TT><PRE>
-#include &#60;u.h&#62;
+#include &lt;u.h&gt;
 
-char c[] = "&#191;&#191;&#191;&#191;&#191; &#191;&#191;";
-Rune s[] = L"&#191;&#191;&#191;&#191;&#191; &#191;&#191;";
+char c[] = "&#12371;&#12435;&#12395;&#12385;&#12399; &#19990;&#30028;";
+Rune s[] = L"&#12371;&#12435;&#12395;&#12385;&#12399; &#19990;&#30028;";
 
 main(void)
 {
@@ -519,8 +519,8 @@ Also defined are several constants relevant to UTF:
 enum
 {
     UTFmax    = 3,    /* maximum bytes per rune */
-    Runesync  = 0x80, /* can't appear in UTF sequence (&#60;) */
-    Runeself  = 0x80, /* rune==UTF sequence (&#60;) */
+    Runesync  = 0x80, /* can't appear in UTF sequence (&lt;) */
+    Runeself  = 0x80, /* rune==UTF sequence (&lt;) */
     Runeerror = 0x80, /* decoding error in UTF */
 };
 </PRE></TT></DL>
@@ -845,7 +845,7 @@ With sorting options enabled, however,
 <TT>sort</TT>
 may need to convert its input to runes: for example,
 option
-<TT>-tALPHA</TT>
+<TT>-t</TT>&#945;<TT></TT>
 requires searching for alphas in the input text to
 crack the input into fields.
 The field specifier
@@ -967,7 +967,7 @@ Unicode equivalent of a plain text terminal.
 With 128 or even 256 characters, a font can be just
 an array of bitmaps.  With 65536 characters,
 a more sophisticated design is necessary.  To store the ideographs
-for just Japanese as 16&#191;16&#191;1 bit images,
+for just Japanese as 16&#215;16&#215;1 bit images,
 the smallest they can reasonably be, takes over a quarter of a
 megabyte.  Make the images a little larger, store more bits per
 pixel, and hold a copy in every running application, and the
@@ -1229,7 +1229,7 @@ work in a language foreign to the keyboard.
 <P>
 For alphabetic languages such as Greek or Russian, it is
 straightforward to construct a program that does phonetic substitution,
-so that, for example, typing a Latin `a' yields the Greek `ALPHA'.
+so that, for example, typing a Latin `a' yields the Greek `&#945;'.
 Within Plan 9, such a program can be inserted transparently
 between the real keyboard and a program such as the window system,
 providing a manageable input device for such languages.
@@ -1277,7 +1277,7 @@ inadequate implementations and converted
 <TT>troff</TT>
 to UTF.
 Rich Drechsler converted his Postscript driver to UTF.
-John Hobby built the Postscript &#191;.
+John Hobby built the Postscript &#9786;.
 We thank them all.
 </P>
 <H4>References
@@ -1317,8 +1317,7 @@ The Unicode Consortium,
 Addison Wesley,
 New York,
 1991.
-
 <br>&#32;<br>
 <A href=http://www.lucent.com/copyright.html>
-Copyright</A> &#169; 2000 Lucent Technologies Inc.  All rights reserved.
+Copyright</A> &#169; 2004 Lucent Technologies Inc.  All rights reserved.
 </body></html>

+ 13 - 6
sys/src/9/pc/pccd

@@ -21,6 +21,7 @@ dev
 	draw		screen vga vgax
 	mouse		mouse
 	vga
+	kbmap
 
 	sd
 	floppy		dma
@@ -41,29 +42,33 @@ link
 	ether589	etherelnk3
 	ether79c970	pci
 	ether8003	ether8390
+	ether8139	pci
+	ether82543gc	pci
 	ether82557	pci
+	ether83815	pci
+	etherdp83820	pci
 	etherec2t	ether8390
 	etherelnk3	pci
-	ether8139	pci
+	etherga620	pci
 	etherigbe	pci ethermii
-	ether82543gc	pci
 	etherga620	pci
 	ethersink
+	ethersmc	devi82365 cis
 	etherwavelan	wavelan devi82365 cis pci
 	ethermedium
 	pcmciamodem
 	netdevmedium
 	usbuhci
-#	usbohci
 
 misc
 	archmp		mp apic
 
 	sdata		pci sdscsi
-	sd53c8xx		pci sdscsi
+	sd53c8xx	pci sdscsi
 	sdmylex		pci sdscsi
 
 	uarti8250
+	uartpci		pci
 
 	vga3dfx		+cur
 	vgaark2000pv	+cur
@@ -74,17 +79,18 @@ misc
 	vgacyber938x	+cur
 	vgaet4000	+cur
 	vgahiqvideo	+cur
-	vgai81x	+cur
+	vgai81x		+cur
 	vgamach64xx	+cur
 	vgamga2164w	+cur
+	vgamga4xx	+cur
 	vganeomagic	+cur
+	vganvidia	+cur
 	vgargb524	=cur
 	vgas3		+cur vgasavage
 	vgat2r4		+cur
 	vgatvp3020	=cur
 	vgatvp3026	=cur
 	vgavmware	+cur
-	vganvidia	+cur
 
 ip
 	il
@@ -99,6 +105,7 @@ port
 
 boot boot #S/sdD0/data
 	il
+	tcp
 	local
 
 bootdir

Some files were not shown because too many files changed in this diff