aboutsummaryrefslogtreecommitdiff
path: root/en/news/status/report-2001-08.xml
blob: bd3b02e07293ada1ed0535cffc54f750b7930e78 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
<!-- $FreeBSD: www/en/news/status/report-august-2001.xml,v 1.5 2003/04/13 16:31:52 hrs Exp $ -->

<report>
  <date>
    <month>August</month>

    <year>2001</year>
  </date>

  <cvs:keywords xmlns:cvs="http://www.FreeBSD.org/XML/CVS" version="1.0">
    <cvs:keyword name="freebsd">
      $FreeBSD: www/en/news/status/report-august-2001.xml,v 1.5 2003/04/13 16:31:52 hrs Exp $
    </cvs:keyword>
  </cvs:keywords>

  <section>
    <title>Introduction</title>

    <p>The FreeBSD Project made substantial progress in the month of
    August, 2001, both on continuing the development of the RELENG_4
    line (4.x-STABLE and 4.x-RELEASE), and on 5.0-CURRENT, the main
    development branch. During this month, the decision was made to
    push the release of 5.0-CURRENT back so that KSE (support for
    fine-grained user threads) could be completed in time for the
    release, rather than postponing that support for 6.0. As such, the
    lifespan of the RELENG_4 line will be extended, with new features
    continuing to be backported to that branch. 4.4-RELEASE went into
    final beta during this month, and will also be available
    shortly.</p>

    <p>This month's edition of the status report has been written with
    the assistance of Nik Clayton and Chris Costello.</p>
  </section>

  <section>
    <title>Future submissions</title>

    <p>For next month, the submission procedures remain the same:
    reports should be between one and two paragraphs long, sent by
    e-mail, and in a format approximately that of this month's
    submissions (Project, Contact, URL, and text). Reminders will be
    mailed to the hackers@FreeBSD.org and developers@FreeBSD.org
    mailing lists at least a week before the deadline; complete
    submission instructions may be found in those reminders.</p>

    <p>-- Robert Watson</p>
  </section>

  <project>
    <title>Fibre Channel Support</title>

    <contact>
      <person>
        <name>
          <given>Matthew</given>

          <common>Jacob</common>
        </name>

        <email>mjacob@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.feral.com/isp.html" />
    </links>

    <body>
      <p>2 Gigabit support was integrated on 8/31/2001 (QLogic
      2300/2312 cards). Because of the author's shrinking time
      commitment for FreeBSD, the previously planned "next step" which
      would have been more complete new CAM Transport integration is
      now probably just the addition of an FC-IP adjunct (as this can
      benefit many platforms simultaneously).</p>
    </body>
  </project>

  <project>
    <title>SCSI Tape Support</title>

    <contact>
      <person>
        <name>
          <given>Matthew</given>

          <common>Jacob</common>
        </name>

        <email>mjacob@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>A major update to error handling was done on 8/28/2001 which
      should correct most of the EOM detection problems that have been
      around for a while. There are several things to fix. The
      principle thing to fix next is the establishment of a loader(8)
      mediated device quirks method.</p>
    </body>
  </project>

  <project>
    <title>CAM</title>

    <contact>
      <person>
        <name>
          <given>Matthew</given>

          <common>Jacob</common>
        </name>

        <email>mjacob@FreeBSD.org</email>
      </person>

      <person>
        <name>
          <given>Justin</given>

          <common>Gibbs</common>
        </name>

        <email>gibbs@FreeBSD.org</email>
      </person>

      <person>
        <name>
          <given>Kenneth</given>

          <common>Merry</common>
        </name>

        <email>ken@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>No change since last status. Some discussion amongst all of us
      occurred, but lack of time and commitment to FreeBSD has meant
      little has actually been committed to the tree. SMPng work will
      be left to those who seem to have a notion about what needs to be
      done.</p>
    </body>
  </project>

  <project>
    <title>Intel Gigabit Ethernet</title>

    <contact>
      <person>
        <name>
          <given>Matthew</given>

          <common>Jacob</common>
        </name>

        <email>mjacob@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>No new status to report. This driver will be worked on again
      soon and cleaned up to work better.</p>
    </body>
  </project>

  <project>
    <title>KSE</title>

    <contact>
      <person>
        <name>
          <given>Julian</given>

          <common>Elischer</common>
        </name>

        <email>julian@elischer.org</email>
      </person>

      <person>
        <name>
          <given>Peter</given>

          <common>Wemm</common>
        </name>

        <email>peter@FreeBSD.org</email>
      </person>

      <person>
        <name>
          <given>Matt</given>

          <common>Dillon</common>
        </name>

        <email>dillon@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>Work in adding supporting infrastructure to the kernel for KSE
      threading support has reached "milestone 2".</p>

      <p>Milestone 2 is where the kernel source consistently refers to
      its resources in terms of per-thread and per-process resources,
      in the way that it will need to when there are &gt; 1 threads per
      process, but the LOGICAL changes to such things as the scheduler,
      and fork and exit, have not yet been made to allow more than one
      thread to be created. (nor have new threading syscalls been added
      yet). This is an important milestone as it represents the last
      point where the kernel has only "mechanical" changes. To go
      further we must start adding new algorithms and functions.</p>

      <p>The kernel for milestone 2 is reliable and has no noticeable
      performance degradations when compared to a matching -current
      kernel. (the differences are less than the margin of error, so
      that sometimes the new kernel actually fractionally beats the
      unaltered kernel).</p>

      <p>We hope that by the time this is published, the KSE patches
      will have been committed. The Major effect for most developers
      will be only that the device driver interface requires a 'thread'
      pointer instead of a Proc pointer in the open, close and ioctl
      entrypoints.</p>

      <p>I'm sure there will be small teething problems but we are not
      expecting great problems at the commit.</p>
    </body>
  </project>

  <project>
    <title>FreeBSD core-secretary</title>

    <contact>
      <person>
        <name>
          <given>Alan</given>

          <common>Clegg</common>
        </name>

        <email>abc@FreeBSD.org</email>
      </person>

      <person>
        <email>core-secretary@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>The position of Core Secretary was filled by Alan Clegg
      &lt;abc@FreeBSD.org&gt; The first core-secretary report should be
      available the second week in September and will cover the issues
      discussed by core during August 2001.</p>
    </body>
  </project>

  <project>
    <title>FreeBSD PAM</title>

    <contact>
      <person>
        <name>
          <given>Mark</given>

          <common>Murray</common>
        </name>

        <email>markm@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>Development is continuing; pam_unix has gained the ability to
      change passwords, login(1) has had PAM made compulsory (and is
      going to have more PAM-capable features handed over to PAM).</p>
    </body>
  </project>

  <project>
    <title>Netgraph ATM</title>

    <contact>
      <person>
        <name>
          <given>Hartmut</given>

          <common>Brandt</common>
        </name>

        <email>brandt@fokus.gmd.de</email>
      </person>
    </contact>

    <body>
      <p>The ATM stack has been tested with a number of FreeBSD
      machines and a Marconi ATM switch and seems to be quite stable
      running CLIP. Multi port support for the native ATM API has been
      implemented but needs some testing.</p>
    </body>
  </project>

  <project>
    <title>PRFW - hooks for the FreeBSD kernel</title>

    <contact>
      <person>
        <name>
          <given>Evan</given>

          <common>Sarmiento</common>
        </name>

        <email>ems@open-root.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.freesoftware.fsf.org/jailuser" />
    </links>

    <body>
      <p>PRFW is a set of hooks for the FreeBSD kernel. It allows users
      to insert code into system calls, for such purposes as creating
      extended security features. Last week, PRFW reached 0.1.0, with
      many bugfixes and cleaning. I urge anyone who is interested to
      please visit the site, join the mailing list. Also take a peek at
      lsm.immunix.org, the Linux hooks. It will be a good contrast.</p>
    </body>
  </project>

  <project>
    <title>CVSROOT script rewrite/tidy</title>

    <contact>
      <person>
        <name>
          <given>Josef</given>

          <common>Karthauser</common>
        </name>

        <email>joe@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>Work is still progressing to make all of the perl scripts run
      using perl's 'strict' mode, and to migrate all FreeBSD specific
      options into the configuration file (CVSROOT/cfg.pm). I'll be
      looking for help soon to write a guide on how to make use of
      these scripts for use in your own repository. Anyone interested
      in helping should contact me at the above email address.</p>
    </body>
  </project>

  <project>
    <title>PPP IPv6 Support</title>

    <contact>
      <person>
        <name>
          <given>Brian</given>

          <common>Somers</common>
        </name>

        <email>brian@freebsd-services.com</email>
      </person>
    </contact>

    <body>
      <p>The software has been committed to -current and seems
      functional. Outstanding issues include dealing with IPV6CP events
      (linkup &amp; linkdown scripts) and allocating site-local and
      global addresses (currently, ``iface add'' is the only way to
      actually use the link).</p>
    </body>
  </project>

  <project>
    <title>Porting ppp to hurd &amp; linux</title>

    <contact>
      <person>
        <name>
          <given>Brian</given>

          <common>Somers</common>
        </name>

        <email>brian@freebsd-services.com</email>
      </person>
    </contact>

    <body>
      <p>Status is unchanged since last month. Patches have been
      submitted to get ppp working under HURD, and mostly under Linux.
      There are GPL copyright problems that need to be addressed. Many
      conflicts are expected after the commit of IPv6 support in
      ppp.</p>
    </body>
  </project>

  <project>
    <title>pppoed</title>

    <contact>
      <person>
        <name>
          <given>Brian</given>

          <common>Somers</common>
        </name>

        <email>brian@freebsd-services.com</email>
      </person>
    </contact>

    <body>
      <p>Making pppoed function in a production environment. All known
      problems have been fixed and committed.</p>
    </body>
  </project>

  <project>
    <title>pppoa</title>

    <contact>
      <person>
        <name>
          <given>Brian</given>

          <common>Somers</common>
        </name>

        <email>brian@freebsd-services.com</email>
      </person>
    </contact>

    <body>
      <p>I looked at bringing PPPoA into the base system, but could not
      because of an overly restrictive distribution license on the
      Alcatel Speedtouch modem firmware. It has been committed as a
      port instead and is running live at a FreeBSD Services client
      site.</p>
    </body>
  </project>

  <project>
    <title>OLDCARD improvements</title>

    <contact>
      <person>
        <name>
          <given>Warner</given>

          <common>Losh</common>
        </name>

        <email>imp@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>The OLDCARD improvements have been completed, except for a few
      edge cases for older laptops with CL-PD6729/30 chips and some pci
      bios issues. Some minor work will continue, but after 4.4R is
      released, only a few remaining bugs will be fixed before the
      author moves on to greener fields of NEWCARD development.</p>
    </body>
  </project>

  <project>
    <title>jpman project</title>

    <contact>
      <person>
        <name>
          <given>Kazuo</given>

          <common>Horikawa</common>
        </name>

        <email>horikawa@psinet.com</email>
      </person>

      <person>
        <email>man-jp@jp.FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.jp.FreeBSD.org/man-jp/" />
    </links>

    <body>
      <p>Targeting 4.4-RELEASE, one team has been translating newly
      MFC'ed section [125678] manpages. The other team has been
      updating section 3 since May and one third (1/3) is finished. The
      port ja-groff is updated to be groff-1.17.2 based, and now it has
      the same functionality as base system does. The port ja-man is
      updated to have the search capability under an architecture
      subdirectory, as base system does. The doc/ja_JP.eucJP/man
      hierarchy update (adding architecture subdirectories) is planned
      after 4.4-RELEASE.</p>
    </body>
  </project>

  <project>
    <title>ARM port</title>

    <contact>
      <person>
        <name>
          <given>Stephane</given>

          <common>Potvin</common>
        </name>

        <email>sepotvin@videotron.ca</email>
      </person>
    </contact>

    <links>
      <url href="http://pages.infinit.net/sepotvin/" />
    </links>

    <body>
      <p>Basic footbridge support is now functional and the kernel is
      now able to probe the pci bus. Access primitives for the bus are
      still missing so I can't attach any drivers yet.</p>
    </body>
  </project>

  <project>
    <title>SYN cache implementation for FreeBSD</title>

    <contact>
      <person>
        <name>
          <given>Jonathan</given>

          <common>Lemon</common>
        </name>

        <email>jlemon@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>The syncache implementation is completed, and currently under
      testing and review. The code should be committed to -current in
      the near future, and a patchset for -stable made available.</p>
    </body>
  </project>

  <project>
    <title>Compressed TCP state</title>

    <contact>
      <person>
        <name>
          <given>Jonathan</given>

          <common>Lemon</common>
        </name>

        <email>jlemon@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>State information for TCP connections is primarily kept in the
      TCP/IP control blocks in the kernel. Not all of the TCP states
      make use of the entire structure, and significant memory savings
      can be had by using a cut-down version of the state in some
      cases. The first phase of this project will address connections
      that are in the TIME_WAIT state by moving them into a smaller
      structure.</p>

      <p>This project has completed the initial research and rough
      design phases, with actual code development starting
      immediately.</p>
    </body>
  </project>

  <project>
    <title>Network SMP locking</title>

    <contact>
      <person>
        <name>
          <given>Jonathan</given>

          <common>Lemon</common>
        </name>

        <email>jlemon@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>For 5.0, the goal is for the network stack to run without the
      Giant lock. Initial development in this area may focus on
      partitioning the code and data structures into distinct areas of
      responsibilities. A first pass of locking may involve using a
      several smaller mini-giant code locks in order to reduce the
      problem to a manageable size.</p>

      <p>Progress for this month includes the creation of a perforce
      repository to officially track the locking changes, and the
      initial submission of locks for the &amp;ifnet list. Some code
      cleanup has also been done to the main tree in order to better
      support future locking additions.</p>
    </body>
  </project>

  <project>
    <title>Network device nodes</title>

    <contact>
      <person>
        <name>
          <given>Jonathan</given>

          <common>Lemon</common>
        </name>

        <email>jlemon@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>Currently, all network devices (fxp0, lo0, etc) exist in their
      own namespace, and are accessed through a socket interface. This
      project creates device nodes in /dev for network devices, and
      allows control and access in that fashion.</p>

      <p>This is experimental work, and suggestions for APIs and
      functionality are strongly encouraged and welcomed. In is not
      clear whether it will be possible (or desirable) to provide the
      exact same set of operations that can be done through the socket
      interface.</p>

      <p>Benefits of approach include the fact that a kqueue filter can
      be attached to a network device for monitoring purposes. Initial
      code exists to send a kq event whenever the network link status
      changes. Other benefits may include better access control by
      using filesystem ACLs to control access to the device.</p>
    </body>
  </project>

  <project>
    <title>RELNOTESng</title>

    <contact>
      <person>
        <name>
          <given>Bruce</given>

          <common>Mah</common>
        </name>

        <email>bmah@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://people.FreeBSD.org/~bmah/relnotes/" />
    </links>

    <body>
      <p>RELNOTESng, the DocBook-ified set of release documentation
      files, has been merged to the RELENG_4 branch. 4.4-RELEASE will
      be the first release of FreeBSD with the new-style release notes,
      hardware list, etc. Some of these documents are being translated
      by the Japanese and Russian translation teams.</p>

      <p>Snapshots of RELNOTESng for CURRENT and 4-STABLE in HTML,
      text, and PDF are available at the above URL and are updated
      irregularly but frequently. Dima Dorfman &lt;dd@FreeBSD.org&gt;
      and Nik Clayton &lt;nik@FreeBSD.org&gt; have been working to have
      automatically-generated snapshots on the main FreeBSD web
      site.</p>

      <p>On my TODO list: 1) Resynchronize the FreeBSD installation
      document with the installation chapter in the Handbook. 2) Update
      the hardware lists (with particular emphasis on PCCARD and USB
      devices). 3) Update the infrastructure to allow the
      architecture-dependent parts of RELNOTESng to scale to more
      hardware platforms.</p>
    </body>
  </project>

  <project>
    <title>FreeBSD/sparc64 port</title>

    <contact>
      <person>
        <name>
          <given>Jake</given>

          <common>Burkholder</common>
        </name>

        <email>jake@FreeBSD.org</email>
      </person>

      <person>
        <name>
          <given>Thomas</given>

          <common>Moestl</common>
        </name>

        <email>tmm@FreeBSD.org</email>
      </person>

      <person>
        <name>
          <given>Robert</given>

          <common>Drehmel</common>
        </name>

        <email>robert@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>Sparc64 development is still continuing rapidly and we're
      making some excellent progress. Of note, some problems with the
      way the pmap module implements copy-on-write mappings have been
      fixed and fork() now works as expected, support for signals has
      been added, and the port has been updated for KSE in the perforce
      repository. Thomas Moestl has begun work on pci bus support, and
      a basic nexus bus for sparc64 has been written. The driver for
      the Sun `Psycho' and `Sabre' UPA-to-PCI bridges and associated
      code has been ported from NetBSD (the Sabre is the on-chip
      version found in the UltraSparc IIi and IIe). PCI configuration,
      I/O and memory space accesses do already work, as well as
      interrupt assignment and delivery for devices attached directly
      to the bridge, and the first PCI device drivers can attach and
      seem to work mostly. Interrupt routing and busdma support still
      need much work.</p>
    </body>
  </project>

  <project>
    <title>Documentation Project</title>

    <contact>
      <person>
        <name>
          <given>Nik</given>

          <common>Clayton</common>
        </name>

        <email>nik@FreeBSD.org</email>
      </person>

      <person>
        <name>
          <common>Documentation Project</common>
        </name>

        <email>doc@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.FreeBSD.org/docs.html" />

      <url href="http://www.FreeBSD.org/docproj/index.html" />
    </links>

    <body>
      <p>The Handbook has been the main focus of activity this month.
      Due to go to the printers on the 15th a vast amount of new
      content has been submitted and committed. This includes a
      complete rewrite of the "Installing FreeBSD", which massively
      expands the amount of information available to people new to
      FreeBSD. It even includes screenshots.</p>

      <p>
        <a
        href="http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/install.html">
        http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/install.html</a>
      </p>

      <p>Comments, and contributions are, of course, welcome.</p>
    </body>
  </project>

  <project>
    <title>IP Multicast Routing support</title>

    <contact>
      <person>
        <name>
          <given>Bill</given>

          <common>Fenner</common>
        </name>

        <email>fenner@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>FreeBSD's IP Multicast Routing support was recently updated in
      several ways. One big change is that it's now able to be loaded
      as a KLD instead of statically compiled into the kernel; this is
      especially useful for experimentation or updating of an existing
      system. It also now coexists nicely with the kernel IP
      encapsulation infrastructure, so that multicast tunnels can
      better coexist with MobileIP, certain IPSec tunnels and generic
      IPv4-in-IPv4 tunnels.</p>
    </body>
  </project>

  <project>
    <title>Mbuf SMPng allocator</title>

    <contact>
      <person>
        <name>
          <given>Bosko</given>

          <common>Milekic</common>
        </name>

        <email>bmilekic@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://people.FreeBSD.org/~bmilekic/code/mb_slab/" />
    </links>

    <body>
      <p>The allocator appears to be stable. Mbtypes statistics have
      been re-activated thanks, in part, to Jiangyi Liu
      &lt;jyliu@163.net&gt; although the diff has not yet been
      committed (I'm just in the process of cleaning it up a little and
      final testing). More work to come: cleanups, follow TODO from the
      original commit, and perhaps an eventual generalization of the
      allocator for various network-related allocations (in a more
      distant future).</p>
    </body>
  </project>

  <project>
    <title>RAIDframe for FreeBSD</title>

    <contact>
      <person>
        <name>
          <given>Scott</given>

          <common>Long</common>
        </name>

        <email>scottl@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://people.FreeBSD.org/~scottl/rf" />
    </links>

    <body>
      <p>After two months of little progress, RAIDframe work is gearing
      up again. The port to -stable has some known bugs but is fairly
      stable. The port to -current was recently completed and patches
      will be released soon. RAIDframe is a multi-platform RAID
      subsystem designed at CMU. This is a port of the NetBSD version
      by Greg Oster.</p>
    </body>
  </project>

  <project>
    <title>aac driver</title>

    <contact>
      <person>
        <name>
          <given>Scott</given>

          <common>Long</common>
        </name>

        <email>scottl@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://people.FreeBSD.org/~scottl/aac" />
    </links>

    <body>
      <p>The aac driver has been given a lot of attention lately and is
      now nearly feature complete. Changes include crashdump support,
      correct handling of controller initiated commands, and more
      complete management interface support. The Linux RAID management
      tool available from Dell and HP now fully works; a FreeBSD native
      version of the tool is also in the works. These changes have been
      checked into -current, and will appear in -stable once 4.4 has
      been released.</p>
    </body>
  </project>

  <project>
    <title>Problem Reports</title>

    <contact>
      <person>
        <name>
          <given>Poul-Henning</given>

          <common>Kamp</common>
        </name>

        <email>phk@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://phk.freebsd.dk/Gnats/" />
    </links>

    <body>
      <p>We are making some progress, we are now down to 2170 open PR's
      down from an all time high of 3270 just 3 months ago. The aim is
      still to get rid of all the dead-wood in the PR database so only
      relevant PRs in the database. A big thanks from me to the people
      who have made this happen!</p>
    </body>
  </project>

  <project>
    <title>network device cloning</title>

    <contact>
      <person>
        <name>
          <given>Brooks</given>

          <common>Davis</common>
        </name>

        <email>brooks@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>Support for cloning vlan devices via ifconfig has been
      committed to -current and will be MFC'd after further testing.
      Additionally, Maksim Yevmenkin submitted code to allow cloning of
      tap and vmnet devices on devfs systems. Code for faith and stf
      should be committed shortly.</p>
    </body>
  </project>

  <project>
    <title>ia64 Port</title>

    <contact>
      <person>
        <name>
          <given>Doug</given>

          <common>Rabson</common>
        </name>

        <email>dfr@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>Current status is that the ia64 kernel builds and runs in a
      simulator environment up to single user mode and has been tested
      lightly in that environment. My current focus is on completing
      the ia64 loader so that I can start to get kernels working on the
      real hardware. The loader is coming along well and I expect to be
      able to load kernels (but not necessary execute them) soon.</p>
    </body>
  </project>

  <project>
    <title>libh Project</title>

    <contact>
      <person>
        <name>
          <given>Alexander</given>

          <common>Langer</common>
        </name>

        <email>alex@FreeBSD.org</email>
      </person>

      <person>
        <name>
          <given>Nathan</given>

          <common>Ahistrom</common>
        </name>

        <email>nra@FreeBSd.org</email>
      </person>
    </contact>

    <body>
      <p>I have access to the libh CVS repo again and am testing a new,
      OBJDIR capable build structure at the moment. Done that, I'm
      going to continue testing the package library and implement the
      missing functionality. Currently, import of libh into the base
      system is under discussion (arch mailinglist). Now that
      5.0-RELEASE has been shifted, I want 5.0 ship with a libh
      installer and package system. We can really need people who are
      good in C++, are able to understand what the current
      implementation does and also feel that working on libh is fun and
      thus are willing to help.</p>
    </body>
  </project>

  <project>
    <title>GNOME Desktop for FreeBSD</title>

    <contact>
      <person>
        <name>
          <given>Maxim</given>

          <common>Sobolev</common>
        </name>

        <email>sobomax@FreeBSD.org</email>
      </person>

      <person>
        <name>
          <common>FreeBSD GNOME Team</common>
        </name>

        <email>gnome@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>Getting GNOME Fifth-Toe metaport ready for 4.4-RELEASE was the
      main focus of activity this month. In the process many components
      were updated, many bugs were tracked down and solved, which
      allowed to make this 97-component meta-package building and
      working properly.</p>

      <p>Next month the project will be focused on organizing work of
      the FreeBSD GNOME Team as well as on attempts to increase amount
      of people participating in the team (anybody who is willing to
      participate is welcome to drop a note to gnome@FreeBSD with a
      short explanation of how he/she could help).</p>
    </body>
  </project>

  <project>
    <title>fbsd-nvdriver</title>

    <contact>
      <person>
        <name>
          <given>Erik</given>

          <common>Greenwald</common>
        </name>

        <email>erik@floatingmind.com</email>
      </person>

      <person>
        <name>
          <given>Joel</given>

          <common>Willson</common>
        </name>

        <email>siigorny@linuxsveeden.borkborkbork</email>
      </person>
    </contact>

    <links>
      <url href="http://fbsd-nvdriver.sourceforge.net" />
    </links>

    <body>
      <p>NVIDIA Corporation releases Linux drivers by using a
      combination of binary object files and source (under a
      constrictive license). The FreeBSD NVIDIA driver project aimed to
      completely replace the source component of the driver using code
      targeting FreeBSD 4.3 and released under the BSD license. The
      binary module provided is supposedly the same module used on
      Windows, BeOS, and OS/2, so it should be portable between
      different i80x86 based OS's.</p>

      <p>The project is currently on indefinite hold. Our contact at
      NVIDIA seemed enthusiastic about the project, and was fairly
      quick about returning email, but when we discovered issues that
      prevented porting without changes to the binary component or
      error codes we needed deciphered, Nick (the contact) said he'd
      look into it and never got back. The first major problem was the
      ioctl interface, the NVIDIA driver passes a pointer and depends
      on the kernel side to copyout the right amount, where FreeBSD
      expect the parameters to be correct and the copyout is performed
      by the subsystem. This was worked around using Dave Rufinos
      "ioctl tunnel" idea. After that, we found that X refused to load
      and traced it down to an ioctl defined in the binary component
      erroring. We cannot tell what that ioctl is, were told that we
      could not sign an NDA for source to that component, and have been
      waiting a month for Nick to "look into it". Therefore progress is
      impossible (without breaking the license) and we believe that the
      flaws make the driver unportable to any *nix other than
      Linux.</p>
    </body>
  </project>

  <project>
    <title>FreeBSD Release Engineering</title>

    <contact>
      <person>
        <name>
          <common>FreeBSD Release Engineer Team</common>
        </name>

        <email>re@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>The FreeBSD release engineering process for FreeBSD 4.4
      started to ramp up around August 1st when the "code slush" took
      affect. During this time all commits to the RELENG_4 branch were
      reviewed by re@FreeBSD.org (over 250 code snippets had to be
      reviewed). After the first release candidate on August 15th, all
      submissions were scrutinized under a more strict potential risk
      vs benefit curve. The best way to help get involved with the
      release engineering process is to simply follow the low volume
      freebsd-qa mailing list, help out with the neverending supply of
      PRs related to our installation tools (sysinstall), or to work on
      a possible next-generation replacement for our installation
      technology, such as the libh or OpenPackages projects.</p>

      <p>Many companies donated equipment, network access, or paychecks
      to finance these activities. Including Compaq, Yahoo!, Wind River
      Systems, and many more.</p>
    </body>
  </project>

  <project>
    <title>Improved TCP Initial Sequence Numbers</title>

    <contact>
      <person>
        <name>
          <given>Mike</given>

          <common>Silbersack</common>
        </name>

        <email>silby@silby.com</email>
      </person>
    </contact>

    <body>
      <p>In mid March, 2001, Tim Newsham of Guardent identified an
      attack possible against the initial sequence number generation
      scheme of FreeBSD (and other OSes.) In order to guard against
      this threat, a randomized sequence number generation scheme was
      ported over from OpenBSD and included in 4.3-release.
      Unfortunately, non-monotonic generation was found to cause major
      problems with applications which initiate continuous, rapid
      connections to a single host.</p>

      <p>In order to restore proper operation under such circumstances
      while still providing strong resistance against sequence number
      prediction, FreeBSD 4.4 uses the algorithm specified in RFC 1948.
      This algorithm hashes together host and port information with a
      piece of secret data to generate a unique sequence number space
      for each connection. As a result, outgoing initial sequence
      numbers are again monotonic, but also unguessable by an
      attacker.</p>
    </body>
  </project>

  <project>
    <title>LOMAC</title>

    <contact>
      <person>
        <name>
          <given>Brian</given>

          <common>Feldman</common>
        </name>

        <email>green@FreeBSD.org</email>
      </person>
    </contact>

    <body>
      <p>The port of LOMAC to FreeBSD is progressing well, and already
      has a very high level of stability (no known outstanding bugs!).
      Aspects which have already been implemented include a stacking
      filesystem overlay with fully-functional access controls (for
      files and directories) based on path names, access controls for
      sending signals, and file-backed-memory revocation for
      processes.</p>
    </body>
  </project>

  <project>
    <title>SMPng</title>

    <contact>
      <person>
        <name>
          <given>John</given>

          <common>Baldwin</common>
        </name>

        <email>jhb@FreeBSD.org</email>
      </person>

      <person>
        <name>
          <given>Peter</given>

          <common>Wemm</common>
        </name>

        <email>wemm@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.FreeBSD.org/~jasone/smp/" />
    </links>

    <body>
      <p>Updates to things from last month: 
      <ul>
        <li>The ast() fixes were committed last month.</li>

        <li>The work on the preemptive kernel is stalled for the time
        being. It is still unstable on Alpha and SMP systems.</li>
      </ul>
      </p>

      <p>New stuff since last month: 
      <ul>
        <li>sx locks now support upgrades and downgrades.</li>

        <li>Witness now supports lock upgrades and downgrades.</li>

        <li>Jason Evans has committed a semaphore implementation.</li>

        <li>Matt Dillon has pushed Giant down into all of the
        syscalls.</li>

        <li>John Baldwin has been working on proc locking in a p4
        'jhb_proc' branch.</li>

        <li>John is also currently working on making the ktrace code
        use a work thread to asynchronously write trace data out to the
        trace file. This will make ktrace safe almost completely MP
        safe with the exception that a few ktrace events need Giant in
        order to call malloc(9) and that ktrgenio() is still
        synchronous. Specifically, however, ktrpsig(), ktrsysret(), and
        ktrcsw() no longer need Giant.</li>

        <li>Jonathan Lemon has started work on locking the network
        stack in a p4 'netlock' branch.</li>
      </ul>
      </p>
    </body>
  </project>

  <project>
    <title>FreeBSD Java Project</title>

    <contact>
      <person>
        <name>
          <given>Greg</given>

          <common>Lewis</common>
        </name>

        <email>glewis@eyesbeyond.com</email>
      </person>
    </contact>

    <links>
      <url href="http://www.FreeBSD.org/java/" />
    </links>

    <body>
      <p>Most of the work this month has focused on development of the
      native JDK 1.3.1 patchset. The 3rd patchset is out and has been
      accompanied with the creation of a FreeBSD "port". This has
      allowed early adopters much easier access to the code and
      naturally resulted in a number of bugs being found. Development
      work has mostly focused on fixing these problems and the project
      is now set to release fourth patchset over the weekend, which
      should see the JDK in a reasonably usable state. One of the big
      challenges left is producing a working HotSpot JVM, which looks
      like it will require some heavy hacking.</p>

      <p>We also welcome OpenBSD's Heikki Korpela to the porting team
      :)</p>
    </body>
  </project>

  <project>
    <title>floppy driver overhaul</title>

    <contact>
      <person>
        <name>
          <given>Joerg</given>

          <common>Wunsch</common>
        </name>

        <email>j@uriah.heep.sax.de</email>
      </person>
    </contact>

    <body>
      <p>As part of some ongoing development activity, the floppy
      driver (fdc(4)) enjoyed some overhaul in the past which is part
      of an ongoing process. Automatic density selection will come
      next, something i meant to implement for years now. As part of
      that, the entire density selection stuff has been rewritten. 2.88
      MB floppies are on the wishlist as well, but I need a working
      2.88 drive before attempting to implement that.</p>
    </body>
  </project>

  <project>
    <title>sppp(4) merge</title>

    <contact>
      <person>
        <name>
          <given>Joerg</given>

          <common>Wunsch</common>
        </name>

        <email>j@uriah.heep.sax.de</email>
      </person>
    </contact>

    <body>
      <p>sppp(4) should be merged with the ISDN4BSD offspring variant.
      This will merge some features and bugfixes from the i4b branch
      (like VJ compression), and eventually end up in a single sppp(4)
      in the tree. While being at that, incorporating many changes and
      bugfixes from NetBSD is considered as well.</p>
    </body>
  </project>

  <project>
    <title>KAME</title>

    <contact>
      <person>
        <name>
          <given>Munechika</given>

          <common>Sumikawa</common>
        </name>

        <email>sumikawa@FreeBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.kame.net/" />
    </links>

    <body>
      <p>The KAME project (http://www.kame.net/) has merged its IPv6
      and IPsec implementation as of July 2001 to FreeBSD CURRENT and
      STABLE, in cooperation with some contributors of the project. The
      latest code includes a number of bug fixes, has been fully tested
      in FreeBSD STABLE, and will appear in FreeBSD 4.4 RELEASE. Thus,
      the new RELEASE version will be quite stable in terms of IPv6 and
      IPsec.</p>

      <p>The project has assigned a talented guy to be responsible for
      merge from KAME to FreeBSD, so future merge efforts will be
      smoother.</p>
    </body>
  </project>

  <project>
    <title>TrustedBSD</title>

    <contact>
      <person>
        <name>
          <given>Robert</given>

          <common>Watson</common>
        </name>

        <email>rwatson@FreeBSD.org</email>
      </person>

      <person>
        <email>trustedbsd-discuss@TrustedBSD.org</email>
      </person>
    </contact>

    <links>
      <url href="http://www.TrustedBSD.org/" />
    </links>

    <body>
      <p>The TrustedBSD project continues to move ahead, with progress
      made in the ACL, Capability, and MAC implementations. In
      addition, support from DARPA is permitting new work to improve
      the extended attribute code, improve security abstractions, and
      work on security documentation. Due to the push-back of the
      FreeBSD 5.0 release, it should now be possible to include a
      complete MAC implementation in that release. Specific status
      reports appear for components where substantial progress is being
      made.</p>
    </body>
  </project>

  <project>
    <title>TrustedBSD Capabilities</title>

    <contact>
      <person>
        <name>
          <given>Robert</given>

          <common>Watson</common>
        </name>

        <email>rwatson@FreeBSD.org</email>
      </person>

      <person>
        <name>
          <given>Thomas</given>

          <common>Moestl</common>
        </name>

        <email>tmm@FreeBSD.org</email>
      </person>

      <person>
        <email>trustedbsd-discuss@TrustedBSD.org</email>
      </person>
    </contact>

    <body>
      <p>Capabilities support is currently being committed to the base
      FreeBSD tree--userland libraries are now fully committed, and
      kernel infrastructure is being integrated.</p>
    </body>
  </project>

  <project>
    <title>BSDCon Europe</title>

    <contact>
      <person>
        <name>
          <given>Paul</given>

          <common>Richards</common>
        </name>

        <email>paul@freebsd-services.com</email>
      </person>
    </contact>

    <body>
      <p>Planning for BSDCon Europe is going well. We're still
      accepting proposals for talks but the schedule is starting to
      fill up so we may not be for much longer.</p>

      <p>An update of the site that includes accommodation information,
      a preliminary schedule, a list of speakers and an online payment
      page will be launched on Wednesday 19 September.</p>

      <p>The fee will be &#163;150 for individuals and &#163;250 for
      corporations. The individual pricing is valid only until the end
      of September, the price will rise to &#163;200 for October and
      late registrations in November will be &#163;250.</p>

      <p>The updated website will include a list of sponsorship
      options, we're still looking for more sponsorship.</p>
    </body>
  </project>
</report>