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
|
<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE report PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for Status Report//EN"
"http://www.FreeBSD.org/XML/www/share/xml/statusreport.dtd">
<!-- $FreeBSD$ -->
<report>
<date>
<month>May - June</month>
<year>2002</year>
</date>
<section>
<title>Introduction</title>
<p>May and June were remarkably busy months for the FreeBSD Project--
FreeBSD developers met in Monterey, CA in June for FreeBSD
Developer Summit III to discuss strategy for the FreeBSD 5.0
release later this year, for the USENIX Annual Technical
conference and for the FreeBSD BoF. Substantial technical progress
was made on FreeBSD 5.0, and FreeBSD 4.6-RELEASE was cut on the
RELENG_4 branch in June.</p>
<p>The remainder of the summer will continue to be busy. Final
components and features for 5.0-RELEASE will go into the tree,
and the development direction will change from new features
to stability, performance, and production-readiness. With
additional 5.0 development previews late in the summer, we
hope to broaden the tester base for the -CURRENT branch,
and start to get early adopters digging out any potential
problems in their test environments. I encourage both FreeBSD
Developers and FreeBSD Users to give 5.0-DP2 a spin (on a machine
without critical data!) and let us know how it goes. The more
testing that happens before the release, the less fixing we have
to do afterwards!</p>
<p>Robert Watson</p>
</section>
<project>
<title>TCP Hostcache</title>
<contact>
<person>
<name>
<given>Andre</given>
<common>Oppermann</common>
</name>
<email>oppermann@pipeline.ch</email>
</person>
</contact>
<body>
<p>The current cache for the TCP metrics is embedded directly into
the routing table route objects. This is highly inefficient as every
route has an empty 56 Byte large metrics structure in it. TCP is the
only consumer (except the MTU and Expiry field) of the structure. A
full view of the Internet routes (110k routes) has more than 6 Mbyte
of unused overhead due to it. The hit rate today is at only approx.
10% in webserver applications. The TCP hostcache will move this entire
metrics structure from the routing table to the TCP stack. Every entry
is a host entry so a simple hash table is sufficient to keep the
entries. Its implementation is much like the TCP Syncache.</p>
<p>The hostcache is going through testing on our servers and will
be ready for committing in September. The results of the TCP metrics
measurement will be used to tune the cache.</p>
</body>
</project>
<project>
<title>IP Routing Table Replacement</title>
<contact>
<person>
<name>
<given>Andre</given>
<common>Oppermann</common>
</name>
<email>oppermann@pipeline.ch</email>
</person>
<person>
<name>
<given>Claudio</given>
<common>Jeker</common>
</name>
<email>jeker@n-r-g.com</email>
</person>
</contact>
<body>
<p>The current Patricia Trie routing table in BSD UNIX is not very
efficient and wastes an enormous amount of space for every node (more
than 256 bytes) (A full Internet view of 110k routes takes 33 MByte
of KVM). Another problem are pointers from and to everywhere
in the routing table. This makes replacing the table very hard and
also significantly increases the table maintenance burden (for example
for some kinds of updates the entire PCB has to be searched linearly).
Also this is a heavy burden for SMP locking. The rewrite focuses on
untangling the pointer mess, making the routing table replaceable
and providing a more IP optimized table (5 MByte for 110k routes).
Other new options include policy routing and some structural alignments
in the network stack for clarity, simplicity and flexibility.</p>
<p>The rewritten IP routing table will be ready for committing in
October.</p>
</body>
</project>
<project>
<title>TCP Metrics Measurement</title>
<contact>
<person>
<name>
<given>Andre</given>
<common>Oppermann</common>
</name>
<email>oppermann@pipeline.ch</email>
</person>
<person>
<name>
<given>Olivier</given>
<common>Mueller</common>
</name>
<email>omueller@8304.ch</email>
</person>
</contact>
<links>
<url href="http://www-t.zhwin.ch/pa02_2/diplomarbeiten2002.pdf">
Diploma Thesis of ZHWIN students, look for Olivier Mueller and Daniel
Graf</url>
</links>
<body>
<p>These students will analyse the tcpdumps of five major Swiss
newspaper websites which give a representative overview of the
user structure in Switzerland. The nice thing about Switzerland
is that is has a very good mix of Modem/ISDN, leased line, Cable,
ADSL and 3G/GSM/GPRS users. Every Internet access technology is
represented. The goal is to analyze the behavior of all TCP
sessions to the monitored sites. Parameters to be analyzed include
TCP session RTT, RTT variance, in/outbound BDP, MSS changes, flow
control behavior, packet loss, packet retransmit and
timing of HTTP traffic to find optimal TCP parameter caching
method.</p>
<p>If you have any other metrics you think is useful please contact
me so I can put that into the job description for the Students. The
study will be made in September and October.</p>
</body>
</project>
<project>
<title>NATD rewrite</title>
<contact>
<person>
<name>
<given>Claudio</given>
<common>Jeker</common>
</name>
<email>jeker@n-r-g.com</email>
</person>
<person>
<name>
<given>Andre</given>
<common>Oppermann</common>
</name>
<email>oppermann@pipeline.ch</email>
</person>
</contact>
<body>
<p>The current natd is pretty powerful in translating different kinds
of traffic but not very powerful in configuration. This project
rewrites natd and parts of libalias to give it a configuration set as
powerful and expressive as the ones in ipf (ipnat) and pf. In addition
it'll use kqueue and will support aliasing to multiple IP
addresses.</p>
<p>The rewritten natd will be ready for committing in early
September.</p>
</body>
</project>
<project>
<title>FreeBSD/ia64</title>
<contact>
<person>
<name>
<given>Peter</given>
<common>Wemm</common>
</name>
<email>peter@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://people.FreeBSD.org/~peter/ia64/">IA64 project
updates and information.</url>
</links>
<body>
<p>IA64 has been progressing slowly. We have access to a prototype
4-way Itaninum2 system from Intel and have managed to get it up and
running to the point of being able to access disk and network with
SMP enabled. We have a big problem with ACPI2.0 and PCI routing
table entries behind pci-pci bridges with no short-term solution
in sight. Various WIP items have been committed to CVS, namely
more complete support for executing 32bit i386 binaries as well
as Marcel Moolenaar's prototype EFI GPT tools.</p>
</body>
</project>
<project>
<title>Libh Status Report</title>
<contact>
<person>
<name>
<given>Antoine</given>
<common>Beaupre</common>
</name>
<email>antoine@usw4.FreeBSD.org</email>
</person>
</contact>
<contact>
<person>
<name>
<given>Alexander</given>
<common>Langer</common>
</name>
<email>alex@FreeBSD.org</email>
</person>
</contact>
<contact>
<person>
<name>
<given>Nathan</given>
<common>Ahlstrom</common>
</name>
<email>nra@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/projects/libh.html" />
<url href="http://usw4.FreeBSD.org/~libh/">libh
new development web page.</url>
<url href="http://usw4.FreeBSD.org/~libh/screenshots">
First snapshots of the diskeditor in action</url>
</links>
<body>
<p>Max has been busy cleaning up the user interface dark side, and has
come up with a plan to improve the build system (using an automated
Makefile dependency generator); the UI design and the TCL glue magic
(using Swig). A development page has been created on usw4, publishing
a lot of information about the current project status, a Changelog,
screenshots, documentation, etc. A new listbox widget has been
implemented, making diskeditor look nicer and more usable. The package
system backend is being inspected and redesigned to conform to a standard
that is itself being re-thought. Indeed, the old sysinstall2.txt text has
been SGML-ized and enhanced and now provides a good (although rough) overview
of libh package system. This allowed the document to be enhanced with diagrams
of how different procedures work. We are therefore getting closer to a
real pkgAPI specification document. The package management tools have been
slightly enhanced and should be a bit more usable, and we started committing
regression test suites in the tree, mostly to test and maintain pkg API
conformance.</p>
<p>So work continues on libh. I plan to take a look at the rhtvision port
to see if it would be better to use it for the tvision backend. I'll keep
on working on the package system to make it really trustworthy, while Max
is continuing his great work on the UI subsystem. I hope to make a new libh
alpha release soon. Note that from now on, libh progress will be published
on the development page.</p>
</body>
</project>
<project>
<title>OLDCARD</title>
<contact>
<person>
<name>
<given>Warner</given>
<common>Losh</common>
</name>
<email>imp@FreeBSD.org</email>
</person>
</contact>
<body>
<p>A major power bug was fixed in oldcard. This caused many
problems for people using PCI interrupts having their machines hang on
boot. This fix has made it into 4.6.1.</p>
<p>Cardbus power is now used on all cardbus bridges that support
it. This means that we now support 3.3V cards on all cardbus
bridges. Before, we only supported them on some of the bridges
because every bridge uses different 3.3V power control when programmed
through the ExCA registers. Now that we're going through the CardBus
bridge's power control register, 3.3V cards work. In fact, for
CardBus bridges, the so called X.XV and Y.YV cards will work in those
bridges that support them. However, X.XV and Y.YV haven't been
defined yet, and no bridges support them (but the bridge interface
define it). Obviously this latter part is untested.</p>
<p>CL-PD6722 support has been augmented slightly. Now it is
possible to instruct the driver which type of 3.3V card detection
strategy to use. There are three choices: none, do it like the
CL-PD6710 does it and do it like the CL-PD6722 does it.</p>
<p>Preliminary support for the CL-PD6729 on a PCI card using PCI
interrupts has been committed. However, it fails for at least one of
the cards like this the author has.</p>
<p>Client drivers can now ask for the manufacturer and model
number of the card without parsing the CIS directly.</p>
<p>Except for fixing bugs and updating pccard.conf entries, no
additional work is planned on the OLDCARD system.</p>
</body>
</project>
<project>
<title>NEWCARD</title>
<contact>
<person>
<name>
<given>Warner</given>
<common>Losh</common>
</name>
<email>imp@FreeBSD.org</email>
</person>
</contact>
<body>
<p>A devd daemon, to replace pccardd and usbd, has been designed.
A few minor bugs have been fixed in NEWCARD. NEWCARD is now the
default in -current. There is an experimental pci/cardbus bus code
merge available as a branch which will be merged into current as soon
as it is stable.</p>
<p>Status: The ed driver, for non-ne2000 clones, is broken and won't
probe. The ata driver won't attach. The sio driver hangs on the
first character. The wi driver is known to work well. Cardbus cards
are generally known to work well, except for some de based cards,
which unfortunately includes the popular Xircom cards. Many systems
fail to work because acpi fails to route interrupts correctly for
non-root pci bridges.</p>
</body>
</project>
<project>
<title>FreeBSD GNOME Project</title>
<contact>
<person>
<name>
<given>Joe</given>
<common>Marcus</common>
</name>
<email>marcus@FreeBSD.org</email>
</person>
<person>
<name>
<given>Maxim</given>
<common>Sobolev</common>
</name>
<email>sobomax@FreeBSD.org</email>
</person>
</contact>
<links>
<!-- A hypertext link with a description... -->
<url href="http://www.FreeBSD.org/gnome/">FreeBSD GNOME Project
Homepage.</url>
</links>
<body>
<p>Things are going well with the FreeBSD GNOME Project. We have just
finished porting the GNOME 2.0 Final development platform and desktop
to FreeBSD! We hope to be able to make GNOME 2.0 the default for
5.0-DP2 and 4.7-RELEASE. In the meantime, we're working to port more
GNOME 2.0 applications.</p>
<p>In order to allow GNOME 1.4.1 applications to work with GNOME 2.0,
we are revamping the GNOME porting infrastructure. GNOME 1.4.1 based
ports are being converted to use the new GNOMENG porting structure.
The specifics of this new system will be written up in the GNOME
porting guide found on the FreeBSD GNOME project homepage.</p>
</body>
</project>
<project>
<title>FreeBSD Java Project</title>
<contact>
<person>
<name>
<given>Greg</given>
<common>Lewis</common>
</name>
<email>glewis@FreeBSD.org</email>
</person>
</contact>
<links>
<!-- A hypertext link with a description... -->
<url href="http://www.FreeBSD.org/java/">FreeBSD Java Project</url>
</links>
<body>
<p>
The BSD Java Porting Team has been making slow but steady progress
on a number of fronts in the last few months. Unfortunately most
of this has occurred behind the scenes, meaning this is a good
opportunity to bring the community up to date.
<ul>
<li>Bill Huey has gotten the Java HotSpot Virtual Machine up and
running on FreeBSD! While dubbing the code of alpha quality,
Bill has been working hard and is able to run major examples
such as the Java 2D demo. This code has hit the repository
and will soon be available.</li>
<li>The port of the 1.4 J2SDK has commenced. The first commits
have gone into the tree, although a first patchset is a
way off yet.</li>
<li>Progress continues with the TCK compliance testing. The
current status has the JDK down to 19 compiler failures
and 183 runtime failures. As we edge closer to compliance
its hoped that example code will be released to allow the
community to pull together through the final few bugs.</li>
<li>A new patchset for JDK 1.3.1 is imminent. This patchset
will include HotSpot for the first time.</li>
</ul>
</p>
</body>
</project>
<project>
<title>KAME Project</title>
<contact>
<person>
<name>
<given>SUZUKI</given>
<common>Shinsuke</common>
</name>
<email>core@kame.net</email>
</person>
</contact>
<links>
<url href="http://www.kame.net/">KAME Project Web Page</url>
<url href="http://www.interop.jp/eng/exhibition/ipv6_showcase.html">IPv6 Showcase at Network+Interop2002</url>
<url href="http://www.interop.jp/jp/exhibition/ipv6_showcase.html">IPv6 Showcase at Network+Interop2002 (detailed, but in Japanase)</url>
<url href="http://www.sfc.wide.ad.jp/~say/n+i/">Pictures of IPv6 Showcase</url>
</links>
<body>
<p>I'm afraid KAME Project does not work actively with regard to FreeBSD in these two month, since
we are too busy with the demonstration of our IPv6 implementation at Networld+Interop 2002 Tokyo.
(Thanks to a great effort, the demonstration was quite successful) </p>
<p>We are aware of netinet6-related bug reports regarding socket handling, fine-grain locking, ip6fw etc.
Regret to say, we could not answer them right now due to the above situation, however we'll discus
these issues internally and determine what to do. </p>
</body>
</project>
<project>
<title>BSDCon 2003</title>
<contact>
<person>
<name>
<given>Gregory</given>
<common>Shapiro</common>
</name>
<email>gshapiro@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.usenix.org/events/bsdcon03/cfp/">Call for papers</url>
</links>
<body>
<p>The BSDCon 2003 Program Committee invites you to contribute original
and innovative papers on topics related to BSD-derived systems and
the Open Source world. Topics of interest include but are not limited
to:
</p>
<ul>
<li> Embedded BSD application development and deployment</li>
<li> Real world experiences using BSD systems</li>
<li> Using BSD in a mixed OS environment</li>
<li> Comparison with non-BSD operating systems; technical,
practical, licensing (GPL vs. BSD)</li>
<li> Tracking open source development on non-BSD systems</li>
<li> BSD on the desktop</li>
<li> I/O subsystem and device driver development</li>
<li> SMP and kernel threads</li>
<li> Kernel enhancements</li>
<li> Internet and networking services</li>
<li> Security</li>
<li> Performance analysis and tuning</li>
<li> System administration</li>
<li> Future of BSD</li>
</ul>
<p> Submissions in the form of extended abstracts are due by April 1, 2003.
Be sure to review the extended abstract expectations before submitting.
Selection will be based on the quality of the written submission and
whether the work is of interest to the community. </p>
<p> We look forward to receiving your submissions! </p>
</body>
</project>
<project>
<title>FreeBSD Release Engineering</title>
<contact>
<person>
<email>re@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/releng" />
</links>
<body>
<p>Over the past few months the FreeBSD Release Engineering Team
oversaw a release process that culminated in the release of
FreeBSD 4.6 for the i386 and Alpha architectures on June 15.
The RE team is currently working concurrently on FreeBSD 4.6.1
and 5.0 DP2. 4.6.1 is a minor point release with an updated SSH
and BIND, fixes for some of the reported ata(4) problems, and
assorted security enhancements that will be detailed in the
release notes. The release engineering activities for 4.6.1 are
taking place on the RELENG_4_6 branch in CVS, while the work on
5.0 DP2 is taking place in Perforce so as not to disturb ongoing
-CURRENT development. We are still committed to FreeBSD 5.0 on
or around November 15, 2002. For more information about
upcoming release schedules, please see our website above. The
RE team would like to thank Sentex Communications for providing
the release builders with access to a fast i386 build machine.
Compaq also donated a couple of fast Alpha build machines to the
project.</p>
</body>
</project>
<project>
<title>Fast IPSEC Status</title>
<contact>
<person>
<name>
<given>Sam</given>
<common>Leffler</common>
</name>
<email>sam@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The main goal of this project is to modify the IPSEC protocols to use
the kernel-level crypto subsystem imported from OpenBSD (see elsewhere). A
secondary goal is to do general performance tuning of the IPSEC
protocols.</p>
<p>Basic functionality is operational for IPv4 protocols. IPv6 support is
coded but not yet tested. Hardware assisted cryptographic operations are
working with good performance improvements. Operation with software-based
cryptographic calculations appears to be at least as good as the existing
implementation. Numerous opportunities for performance improvements have
been identified.</p>
<p>This work is currently being done in the -stable tree. A port to
the -current tree is about to start.</p>
</body>
</project>
<project>
<title>FreeBSD C99 & POSIX Conformance Project</title>
<contact>
<person>
<name>
<given>Mike</given>
<common>Barcroft</common>
</name>
<email>mike@FreeBSD.org</email>
</person>
<person>
<name>
<common>FreeBSD-Standards Mailing List</common>
</name>
<email>standards@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/projects/c99/" />
</links>
<body>
<p>Since the last status report, the following utilities have been
brought up to conformance (at least to some degree) with POSIX.1-2001,
they include: asa(1), cd(1), compress(1), ctags(1), ls(1), newgrp(1),
nice(1), od(1), pathchk(1), renice(1), tabs(1), tr(1), uniq(1), wc(1),
and who(1). In addition, development is taking place on bringing the
BSD SCCS suite up to date with newer standards.</p>
<p>On the API front, printf(9) has been given support for the `j' and
'n' flags, waitpid(2) now supports the WCONTINUED option, and an
implementation of fstatvfs() and statvfs() has been committed. An
implementation of utmpx is in progress, which has an aim to address
some of the major problems with the current utmp. Several headers
have been brought up to conformance with POSIX.1-2001, they include:
<netinet/in.h>, <pwd.h>, <sys/statvfs.h>, and
<sys/wait.h>.</p>
</body>
</project>
<project>
<title>Hardware Crypto Support Status</title>
<contact>
<person>
<name>
<given>Sam</given>
<common>Leffler</common>
</name>
<email>sam@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The goal of this project is to import the OpenBSD kernel-level crypto
subsystem. This facility provides kernel- and user-level access to hardware
crypto devices for the calculation of cryptographic hashes, ciphers, and
public key operations. The main clients of this facility are the kernel RNG
(/dev/random), network protocols (e.g. IPSEC), and OpenSSL (through the
/dev/crypto device).</p>
<p>The software has been available as a patch against the -stable tree for
about six months. The core crypto support is tested, including device
drivers for the Hifn 7951, and Broadcom 5805, 5820, and 5821 parts. Recent
work has concentrated on fixing device driver bugs, fixing support for Hifn
7811 parts, adding support for public key operations, and adding
flow-control between the crypto layer and device drivers. Future work
includes porting this facility to the -current tree.</p>
</body>
</project>
<project>
<title>KSE (Kernel schedulable Entity) thread support </title>
<contact>
<person>
<name>
<given>Julian</given>
<common>Elischer</common>
</name>
<email>julian@FreeBSD.org</email>
</person>
<person>
<name>
<given>Dan</given>
<common>Eischen</common>
</name>
<email>deischen@FreeBSD.org</email>
</person>
</contact>
<links>
<!-- A hypertext link with a description... -->
<url href="http://www.freebsd.ord/~julian/">Some info
here.</url>
</links>
<body>
<p>
The project took a major step at the beginning of July when
Milestone-III was committed. Milestone-III allows a simple test
program (available at /usr/src/tools/KSE/ksetest/)
to run multiple threads, using kernel support. It does not yet
allow the ability to allow these threads to run on different CPUs
simultaneously. Milestone IV will be to allow this, however
Milestone-III should allow Dan to start (with any interested
parties) to start prototyping the userland part of the
system. Milestone-III is only currently usable on x86, and
does not include some of the
requirements for full thread-control, suspension etc. that
will be required later. </p>
<p>
Before M-IV is started some small tweaking is likely
in the central sources on M-III as we discover issues
as we try to get the userland jumpstarted. These will have no
effect on non-KSE processes, (i.e. all of them :-) and
should not be an issue for other developers. </p>
<p>
A tex/fig->html guru is needed to help maintain the
KSE web page (not mentioned above as it is broken).
</p>
</body>
</project>
<project>
<title>SMPng Status Report</title>
<contact>
<person>
<name>
<given>John</given>
<common>Baldwin</common>
</name>
<email>jhb@FreeBSD.org</email>
</person>
<person>
<email>smp@FreeBSD.org</email>
</person>
</contact>
<links/>
<body>
<p>The SMPng project has continued to make steady progress in
the past two months. Jeff Roberson completed the switch over
to UMA for the general kernel malloc() and free() pushing down
Giant appropriately so that callers of malloc() and free() are
no longer required to hold Giant. Alan Cox continues to clean
up the locking in the VM system pushing down Giant in several
of the VM related system calls. Jeffrey Hsu committed locking
for TCP/IP protocol control blocks in the network stack. John
Baldwin committed the changes to the p_canfoo() API to use
thread credentials for subject threads and added appropriate
locking for the targer process credentials. Support for
adaptive mutexes on SMP systems as well as the new IA32 PAUSE
instruction were also committed in May. The kernel tracing
facility KTRACE also received an overhaul such that the
majority of its work was pushed out into a worker thread
allowing trace points to no longer require Giant. Andrew
Reiter has also been pushing down Giant in several system
calls.</p>
<p>Bosko continues to work on light-weight interrupt threads
for i386. Most of the bugs in the turnstile code have been
found and fixed; however, the turnstile and preemption
patches have temporarily been put on hold so that more
emphasis can be placed on fixing bugs and making -current
more stable in preparation for 5.0 release in November.
Alan Cox and Andrew Reiter are continuing the work mentioned
above. Jeff Roberson is also working on fixing the current
vnode locking in VFS. Peter Wemm has also started to tackle
TLB issues on SMP in the i386 pmap again as well.</p>
</body>
</project>
<project>
<title>FreeBSD Security Officer Team</title>
<contact>
<person>
<name>
<given>Jacques</given>
<common>Vidrine</common>
</name>
<email>nectar@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/security"/>
</links>
<body>
<p>After an outstanding job serving the project as Security Officer
for over a year, Kris stepped down in January in order to focus more
of his time pursuing his PhD. I offered to attempt to fill the vacant
role.</p>
<p>This is the first report by the SO Team. Notable events since
the beginning of 2002 follow.</p>
<p>28 FreeBSD Security Advisories have been issued, 16 of which
were regarding the base system. Of those sixteen, 8 affected only
FreeBSD.</p>
<p>FreeBSD Security Notices were introduced, and four have been
issued so far. The Security Notices cover issues that are not
regarded as critical enough to warrant a Security Advisory. So far
only Ports Collection issues (i.e. vulnerabilities in optional 3rd
party packages) have been reported in Security Notices. The first
four Security Notices covered 53 individual issues.</p>
<p>Issues reported to the SO team are now being tracked using a
RequestTracker ticket database.</p>
<p>The SO team has undergone membership changes, as well as some
changes in internal organization. The membership and organization
has also been made publicly visible on the FreeBSD Security Officer
web page.</p>
</body>
</project>
<project>
<title>jpman project</title>
<contact>
<person>
<name>
<given>Kazuo</given>
<common>Horikawa</common>
</name>
<email>horikawa@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.jp.FreeBSD.org/man-jp/">jpman project</url>
</links>
<body>
<p>For 4.6-RELEASE, we announced the package ja-man-doc-4.6.tgz
which is in sync with 4.6-RELEASE base system manual pages
except for perl5 pages (jpman project do not maintain them).
Continuing section 3 updating has 88% finished.</p>
</body>
</project>
<project>
<title>FreeBSD/KGI Status Report</title>
<contact>
<person>
<name>
<given>Nicholas</given>
<common>Souchu</common>
</name>
<email>nsouch@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/~nsouch/ggiport.html"> Project URL</url>
</links>
<body>
<p>Progression is slow, but the effort is maintained. Most of fb over KGI has been
written in parallel with a KGI display driver based on fb.
DDC/DDC2 is being discussed for Plug & Play monitor support. KGI aims at providing
a generic OS independent interface which would take advantage of FreeBSD I2C (iic(4))
infrastructure.
</p>
</body>
</project>
<project>
<title>UFS2 - Extended attribute and large size support for UFS</title>
<contact>
<person>
<name>
<given>Poul-Henning</given>
<common>Kamp</common>
</name>
<email>phk@FreeBSD.org</email>
</person>
<person>
<name>
<given>Kirk</given>
<common>Mckusick</common>
</name>
<email>mckusick@FreeBSD.org</email>
</person>
</contact>
<body>
<p>
UFS2 is an extension to the well-known UFS filesystem which
using a new inode format adds support for "64bit everywhere"
and later for extended attribute support, in addition to the
current UFS features: soft-updates and snapshots.
</p>
<p>
The basic UFS2 code has been committed and work on the extended
attribute interface and vnode operations will continue.
</p>
</body>
</project>
<project>
<title>GEOM - generalized block storage manipulation</title>
<contact>
<person>
<name>
<given>Poul-Henning</given>
<common>Kamp</common>
</name>
<email>phk@FreeBSD.org</email>
</person>
</contact>
<links>
<!-- A hypertext link with a description... -->
<url href="http://www.FreeBSD.org/~phk/Geom/">Old concept paper here.</url>
</links>
<body>
<p>
The GEOM code has gotten so far that it beats our current code
in some areas while still lacking in others. The goal is for
GEOM to be the default in 5.0-RELEASE.
</p>
<p>
Currently work on a cryptographic module which should be able
to protect a diskpartition from practically any sort of attack
is progressing.
</p>
</body>
</project>
<project>
<title>OpenOffice.org for FreeBSD</title>
<contact>
<person>
<name>
<given>Martin</given>
<common>Blapp</common>
</name>
<email>mbr@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://projects.imp.ch/openoffice">OpenOffice.org FreeBSD port Homepage</url>
</links>
<body>
<p>The port of openoffice 1.0 has been finished. Most showstopper issues
with rtld, libc and our toolchain have been fixed. There is one remaining
deadlock in the web-browser code of OO.org. If anybody like to help
us with fixing this bug (may be another libc_r bug as it looks like)
just mail me! Unfortunately gcc2 support got broken again with the import
of gcc2.95.4 in STABLE. Exceptions support seems to be broken again; we get
internal compiler errors with c++ exceptions code. You'll have to use gcc31
again.</p>
<p>Since our package cluster is outdated and can not build OO.org packages
anytime soon, I did my own little package cluster and can now offer
packages for 4.6R for 16 different languages. They can be found on the
project homepage.</p>
<p>Porting of OpenOffice1.0.1 is on it's way. A beta port and a package have
been made available on the project homepage.</p>
</body>
</project>
<project>
<title>Lightweight Interrupt Scheduling</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/~peter/p4db/chb.cgi?FSPC=//depot/projects/interrupt/sys/...">
The interrupt p4 branch</url>
</links>
<body>
<p>The lightweight interrupt scheduling code makes scheduling an
interrupt on i386 without having to grab the sched_lock possible,
and also avoids a full-blown context switch.</p>
<p>Currently, the code in the p4 branch works, although needs a
little bit of cleanup and, most importantly, requires a merge to
post-KSE III. Now that stuff seems to have stabilized a bit, I'm
waiting to get a little time (and nerve) to do the merge. Also,
looking forward for some KSE interface that will allow for "KSE
borrowing," which would make this cleaner with regards to KSE and
lightweight interrupts. This is a 5.0 feature.</p>
</body>
</project>
<project>
<title>TIRPC port for BSD sockets</title>
<contact>
<person>
<name>
<given>Martin</given>
<common>Blapp</common>
</name>
<email>mbr@FreeBSD.org</email>
</person>
</contact>
<links>
<!-- A hypertext link with a description... -->
<url href="http://www.attic.ch/tirpc">TIRPC for FreeBSD Homepage</url>
<!-- And/or one without. -->
<url href="http://www.attic.ch/tirpc" />
</links>
<body>
<p>
A lot of remaining PR's and Bugs have been closed. All relevant rpc
concerning patches have been committed. Thanks go to Alfred and Ian Dowese.
</p>
<p>Jean-Luc Richier <Jean-Luc.Richier@imag.fr> has made a patch
available which adds IPv6 support to all remaining rpc servers.
See ftp://ftp.imag.fr/pub/ipv6/NFS/NFS_IPV6_FreeBSD5.0.gz and
ftp://ftp.imag.fr/pub/ipv6/NFS/0README_NFS_IPV6_FreeBSD5.0
We will check his code and add it to CURRENT ASAP.</p>
<p>A first commit part from TIRPC99 has been done. I'm working now
on porting the remaining parts so when FreeBSD 5.0 gets released,
it will be TIRPC99 based. This will happen together with the NetBSD
project, as they use the same codebase as we do.
</p>
</body>
</project>
<project>
<title>mb_alloc updates</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_alloc/">Some
[Old] mb_alloc stuff</url>
</links>
<body>
<p>mb_alloc is getting some updates and a couple of optimizations.
A new allocator interface routine should already be committed by
the time this report is "published:" m_getcl() allocates an mbuf
and a cluster in one shot. This is the result of months
(literally) of requests from Alfred and, recently, Luigi - who,
coincidentally, is the author of the same [upcoming] routine in -STABLE.</p>
<p>Other than that, mb_alloc is being shown how to perform
multi-mbuf or cluster allocations without dropping the cache lock in
between (m_getcl() and m_getm() will use this). Finally, work is
being done to optimize ext_buf ref. count allocations and to provide
support for jumbo (> 9K) clusters.</p>
</body>
</project>
<project>
<title>Improving FreeBSD Startup Scripts</title>
<contact>
<person>
<name>
<given>Doug</given>
<common>Barton</common>
</name>
<email>DougB@FreeBSD.org</email>
</person>
</contact>
<contact>
<person>
<name>
<given>Mike</given>
<common>Makonnen</common>
</name>
<email>makonnen@pacbell.net</email>
</person>
</contact>
<contact>
<person>
<name>
<given>Gordon</given>
<common>Tetlow</common>
</name>
<email>gordont@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://groups.yahoo.com/group/FreeBSD-rc/links/">
The Yahoo! group site for discussion of this project
</url>
</links>
<body>
<p>We are making excellent progress. There is a fully functioning
implementation imported to -current now. We need as many people as
possible to rc_ng equal to YES in /etc/rc.conf.</p>
<p>The next step is to set the default to YES, which we plan to do
before DP 2.</p>
</body>
</project>
<project>
<title>ipfw2</title>
<contact>
<person>
<name>
<given>Luigi</given>
<common>Rizzo</common>
</name>
<email>luigi@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.iet.unipi.it/~luigi/" />
</links>
<body>
<p>In summer 2002 the native FreeBSD firewall has been completely
rewritten in a form that uses BPF-like instructions
to perform packet matching in a more effective way. The external
user interface is completely backward compatible, though you can
make use of some newer
match patterns (e.g. to handle sparse sets of IP addresses) which
can dramatically simplify the writing of ruleset (and speed up
their processing).
The new firewall, called ipfw2, is much faster and easier to
extend than the old one. It has been already included in
FreeBSD-CURRENT, and patches for FreeBSD-STABLE are available
from the author.
</p>
</body>
</project>
<project>
<title>jp.FreeBSD.org daily SNAPSHOTs project</title>
<contact>
<person>
<name>
<given>Makoto</given>
<common>Matsushita</common>
</name>
<email>matusita@jp.FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://snapshots.jp.FreeBSD.org/">Project Webpage</url>
<url href="http://www.jp.FreeBSD.org/snapshots/">Project Webpage (in Japanese
)</url>
<url href="http://snapshots.jp.FreeBSd.org:8021">SNAPSHOTs anonftp area on the web</url>
<url href="ftp://daemon.jp.FreeBSD.org/pub/FreeBSD/releases/i386/">Release branch snapshots for FreeBSD/i386</url>
</links>
<body>
<p>
I spent busy days in last two months, many new topics are emerged
from the project. We now support FreeBSD/alpha 5-current
distribution by cross-compiling on the x86 PC. Anonymous ftp area
is now exported to the yet another web server. Our release branch
snapshots are relocated to daemon.jp.FreeBSD.org because of our
CPU/network bandwidth problem.
</p>
<p>
I'm seriously considering to solve the lack of CPU and network
resources for the project's future evolution. Maybe the bandwidth
problem can be resolved (several bandwidth offers have been received!),
but there is no answer about CPU problems (I have a plan to upgrade
our PCs from P3-500MHz to P4 or better).
If you have interested in donating PCs to the project, please email me
for more detail.
</p>
</body>
</project>
<project>
<title>Userland Regression Tests</title>
<contact>
<person>
<name>
<given>Juli</given>
<common>Mallett</common>
</name>
<email>jmallett@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Regression tests for many bugs fixed in text manipulation utilities
have been added, as well as tests for various non-standard versions
of functionality that FreeBSD users should expect. A library of
m4 macros for creating the tests themselves has been added.</p>
</body>
</project>
<project>
<title>Single UNIX Specification conformant SCCS suite</title>
<contact>
<person>
<name>
<given>Juli</given>
<common>Mallett</common>
</name>
<email>jmallett@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The final version of SCCS distributed by CSRG has been integrated
into the projects CVS repository, and worked on extensively to the
point where essential functionality works on FreeBSD (and other
operating systems). Some standards-related functionality has been
implemented</p>
</body>
</project>
<project>
<title>Zero Copy Sockets status report</title>
<contact>
<person>
<name>
<given>Ken</given>
<common>Merry</common>
</name>
<email>ken@FreeBSD.org</email>
</person>
</contact>
<links>
<!-- A hypertext link with a description... -->
<url href="http://people.FreeBSD.org/~ken/zero_copy/">Zero copy patches
and information. </url>
</links>
<body>
<p> The zero copy sockets code was committed to FreeBSD-current on June
25th, 2002. I'm not planning on doing any more patches, although
I will leave the web page up as it contains useful information. </p>
<p>
Many thanks to the folks who have tested and reviewed the code over
the years. </p>
</body>
</project>
<project>
<title>locking up pcb's in the networking stack</title>
<contact>
<person>
<name>
<given>Jeffrey</given>
<common>Hsu</common>
</name>
<email>hsu@FreeBSD.org</email>
</person>
</contact>
<links/>
<body>
<p>Jennifer Yang's patch was committed June 10 for the BSD Summit.
After a few bugs which were reported initially and
fixed that same week, networking in -current
has been stable, including the parts that were not locked up,
like IPv6. Work is on-going to lock up the rest of the stack.</p>
</body>
</project>
<project>
<title>Bluetooth stack for FreeBSD (Netgraph implementation)</title>
<contact>
<person>
<name>
<given>Maksim</given>
<common>Yevmenkin</common>
</name>
<email>m_evmenkin@yahoo.com</email>
</person>
</contact>
<links>
</links>
<body>
<p>
Not much to report. Another engineering snapshot is available
for download at
http://www.geocities.com/m_evmenkin/ngbt-fbsd-20020709.tar.gz.
If anyone has Bluetooth hardware and spare time please join in and help
me
with testing.
</p>
<p>
This snapshot includes basic support for USB devices and manual pages.
The HCI layer now has support for multiple control hooks. All HCI
transport
drivers (H4, BT3C and UBT) has been changed to provide consistent
interface
to the rest of the world. Some userspace utilities have been changed as
well.
</p>
<p>
Still no support for RFCOMM (Serial port emulation over Bluetooth link)
and
SDP (Service Discovery Protocol). Several design flaws have been
discovered
and it might take some time to resolve these issues.
</p>
</body>
</project>
<project>
<title>TrustedBSD MAC</title>
<contact>
<person>
<name>
<given>Robert</given>
<common>Watson</common>
</name>
<email>rwatson@FreeBSD.org</email>
</person>
<person>
<name>
<given>TrustedBSD Discussion Mailing List</given>
</name>
<email>trustedbsd-discuss@TrustedBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.TrustedBSD.org/">TrustedBSD main web page</url>
</links>
<body>
<p>The TrustedBSD Project has been busy in May and June,
developing new features, presenting on the technology at
the FreeBSD Developer Summit, and improving the readiness
of the MAC branch for integration into the main FreeBSD
tree. The migration to dynamic labeling in the TrustedBSD
MAC framework is complete, with all policies now making
use of dynamic labels in the kernel. This permits policies
to associate arbitrary additional security data with a
variety of kernel objects at run-time. Implement mac_test,
a sanity checking module. Pass labels as well as objects
to each policy entry point to reduce knowledge of label
storage in the policies. Implement mac_partition, a simple
jail-like policy. Adapt the MAC framework for process locking.
</p>
<p>
Improve support for sockets: provide a peerlabel maintained for
stream sockets (unix domain, tcp), entry points for accept,
bind, connect, listen. Improve support for IPv4 and IPv6 by
labeling IP fragment reassembly queues, and providing entry
points to instrument fragment matching, update, reassembly, etc.
Locally disable KAME if_loop mbuf contiguity hack because it
drops labels on mbufs: we need to make sure the label is
propagated. Label pipes and provide access control for them.
Improve vnode labeling: now handle labeling for devfs, pseudofs,
procfs. Fix interactions between MAC and ACLs relating to the
new VAPPEND flag.</p>
<p> SELinux policy tools now ported to SEBSD. SEBSD now labels
subjects and file system objects.
Provide ugidfw, a tool for managing rules for the mac_bsdextended
policy.</p>
<p> Massive diff reduction. KSEIII merged. Main tree integration
will begin shortly.</p>
<p>Updated prototype code may be retrieved from the TrustedBSD
CVS trees on cvsup10.FreeBSD.org.</p>
</body>
</project>
</report>
|
