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
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
|
<?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/sgml/statusreport.dtd">
<report>
<date>
<month>January-April</month>
<year>2005</year>
</date>
<section>
<title>Introduction</title>
<p>The first quarter of 2005 has been extremely active in both
FreeBSD-CURRENT and -STABLE. With FreeBSD 5.4 in the final RC stage
and an anticipated branch of FreeBSD-6 this summer we have seen a lot
of performance improvements in 5 and a couple of exciting new
features in 6.</p>
<p>The report turnout was extremely good and it seems that the
webform provided by Julian Elischer has made it more enjoyable to
write reports. Many thanks to Julian for providing this. We also
like to get your attention to the open tasks section provided in some
reports.</p>
<p>On special note, please take a look at the report about the
upcoming BSDCan in Ottawa. There will be lots of interesting FreeBSD
related talks and activities. If you enjoy reading these reports, you
will love the conference. See you there!</p>
<p>Thanks to all the reporters, we hope you enjoy reading.</p>
</section>
<category>
<name>proj</name>
<description>Projects</description>
</category>
<category>
<name>doc</name>
<description>Documentation</description>
</category>
<category>
<name>kern</name>
<description>Kernel</description>
</category>
<category>
<name>net</name>
<description>Network infrastructure</description>
</category>
<category>
<name>bin</name>
<description>Userland programs</description>
</category>
<category>
<name>arch</name>
<description>Architectures</description>
</category>
<category>
<name>ports</name>
<description>Ports</description>
</category>
<category>
<name>vendor</name>
<description>Vendor / 3rd Party Software</description>
</category>
<category>
<name>misc</name>
<description>Miscellaneous</description>
</category>
<project cat='proj'>
<title>Secure Updating</title>
<contact>
<person>
<name>
<given>Colin</given>
<common>Percival</common>
</name>
<email>cperciva@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.daemonology.net/portsnap/" />
<url href="http://www.daemonology.net/freebsd-update/" />
</links>
<body>
<p>Shortly before the ports freeze for FreeBSD 5.4, I released a
new version of Portsnap. In addition to being secure and more
efficient than CVSup, this latest version distributes INDEX,
INDEX-5, and INDEX-6 files, thereby eliminating the need to run
"make fetchindex" and ensuring that the ports INDEX will match the
existing ports tree. In addition, portsnap builds have now moved
onto hardware managed by the FreeBSD project, thereby sharply
increasing portsnap's chances of survival if I get hit by a
bus.</p>
<p>In early February hardware problems caused both FreeBSD Update
and Portsnap to stop functioning for a few days, but those were
resolved thanks to a server donated by layeredtech.com.</p>
<p>I intend bring Portsnap into the FreeBSD base system before the
end of the month, followed by FreeBSD Update a few months
later.</p>
</body>
</project>
<project cat='project'>
<title>if_bridge from NetBSD</title>
<contact>
<person>
<name>
<given>Andrew</given>
<common>Thompson</common>
</name>
<email>andy@fud.org.nz</email>
</person>
</contact>
<links>
<url href="http://www.fud.org.nz/~andy/if_bridge.diff" />
</links>
<body>
<p>This project aims to import the bridging code and interface from
NetBSD and OpenBSD. The bridge is a cloned interface which can be
modified by ifconfig and brconfig. It supports assigning an IP
address directly to the bridge (e.g. bridge0) instead of one of the
member interfaces, and can be used with tcpdump to inspect the
bridged packets. The code also supports spanning tree (802.1D) for
loop detection and link redundancy. Any pfil(9) packet filter can
be used to filter the bridged packets.</p>
</body>
<help>
<task>Testing performance and functionality against the existing
bridge code. Testers welcome!</task>
</help>
</project>
<project cat='arch'>
<title>ARM Support for TS-7200</title>
<contact>
<person>
<name>
<given>John-Mark</given>
<common>Gurney</common>
</name>
<email>jmg@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.embeddedarm.com/epc/ts7200-spec-h.html">
TS-7200 Board</url>
<url
href="http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/jmg/arm&HIDEDEL=NO">
Perforce Code Location</url>
<url href="http://people.freebsd.org/~jmg/dmesg.ts7200">FreeBSD/arm
TS-7200 dmesg output</url>
</links>
<body>
<p>I have been working on getting FreeBSD/arm running on the
TS-7200. So far the board boots, and has somewhat working ethernet
(some unexplained packet loss). I can netboot from a FreeBSD/i386
machine, and I can also mount msdosfs's on CF.</p>
</body>
<help>
<task>Figuring out why some small packets transmit with
error</task>
<task>EP93xx identification information to properly attach various
onboard devices</task>
</help>
</project>
<project cat='ports'>
<title>Update of the Linux userland infrastructure</title>
<contact>
<person>
<name>
<given>Alexander</given>
<common>Leidinger</common>
</name>
<email>netchild@FreeBSD.org</email>
</person>
<person>
<name>
<given>Emulation</given>
<common>Mailinglist</common>
</name>
<email>freebsd-emulation@FreeBSD.org</email>
</person>
</contact>
<links>
</links>
<body>
<p>The update to RedHat 8 as discussed in the last status report
went smoothly (just some minor glitches which got resolved
fast).</p>
<p>As a next step a cleanup/streamlining and the possibility of
overriding the default Linux base is in progress. This depends on
changes which need at least one testrun on the ports build cluster,
so the final date for those changes depends upon the availability
of the cluster resources.</p>
</body>
<help>
<task>Refactoring the common RPM code into bsd.rpm.mk.</task>
<task>Determining which up-to-date Linux distribution to use as the
next default Linux base. Important criteria:
<ul>
<li>RPM based (to be able to use the existing
infrastructure)</li>
<li>good track record regarding availability of security
fixes</li>
<li>packages available from several mirror sites</li>
<li>available for several hardware architectures (e.g. i386,
amd64, sparc64; Note: not all architectures have a working
linuxolator for their native bit with, but as long as there are
no userland bits available, no motivation regarding writing the
kernel bits will arise)</li>
</ul>
</task>
<task>Moving the linuxolator userland to an up-to-date version (see
above).</task>
</help>
</project>
<project cat='bin'>
<title>Pipe namespace added to portalfs</title>
<contact>
<person>
<name>
<given>Diomidis</given>
<common>Spinellis</common>
</name>
<email>dds@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.spinellis.gr/blog/20050413/index.html" />
</links>
<body>
<p>A new sub-namespace, called pipe, has been added to portalfs.
The pipe namespace executes the named command, starting back at the
root directory. The command's arguments can be provided after the
command's name, by separating them with spaces or tabs. Files
opened for reading in the pipe namespace will receive their input
from the command's standard output; files opened for writing will
send the data of write operations to the command's standard input.
The pipe namespace allows us to perform scatter gather operations
without using temporary files, create non-linear pipelines, and
implement file views using symbolic links.</p>
</body>
</project>
<project cat='kern'>
<title>Low-overhead performance monitoring for FreeBSD</title>
<contact>
<person>
<name>
<given>Joseph</given>
<common>Koshy</common>
</name>
<email>jkoshy@FreeBSD.org</email>
</person>
</contact>
<links>
<url
href="http://people.freebsd.org/~jkoshy/projects/perf-measurement">
Project home page</url>
</links>
<body>
<p>Many modern CPUs have on-chip performance monitoring counters
(PMCs) that can be used to count low-level hardware events like
instruction retirals, branch mispredictions, cache and TLB misses
and the like. PMC architectures and capabilities vary between CPU
vendors and between CPU generations from the same vendor, making
the creation of portable applications difficult. This project
attempts to provide a uniform API for applications to use, and the
necessary infrastructure to "virtualize" and manage the available
PMC hardware resources. The creation of performance analysis tools
that use this infrastructure is also part of the project's
goals.</p>
<p>Work since the last status report:</p>
<ul>
<li>Support for Intel
Pentium-Pro/Pentium-II/Pentium-III/Pentium-M/Celeron style PMCs
has been added.</li>
<li>The Pentium-4/HTT machine dependent layer has been
overhauled.</li>
<li>A Python language interface to the C library interface pmc(3)
has been written.</li>
<li>Many bugs have been fixed and documentation has been
updated.</li>
</ul>
</body>
<help>
<task>The code needs to be tested on Intel Pentium-M, Celeron,
Pentium II and Pentium Pro CPUs.</task>
</help>
</project>
<project cat='proj'>
<title>GELI - GEOM class for providers encryption</title>
<contact>
<person>
<name>
<given>Pawel Jakub</given>
<common>Dawidek</common>
</name>
<email>pjd@FreeBSD.org</email>
</person>
</contact>
<links>
<url
href="http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/pjd/geom%5fclasses/sys/geom/eli&HIDEDEL=NO">
Kernel module.</url>
<url
href="http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/pjd/geom%5fclasses/sbin/geom/class/eli&HIDEDEL=NO">
Userland configuration utility.</url>
</links>
<body>
<p>GELI is a GEOM class used for GEOM providers encryption. I
decided to work on this, as I needed some feature, which cannot be
found in similar projects. Here is the list of features, I found
interesting:</p>
<ul>
<li>makes use of crypto(9)</li>
<li>if there is a crypto hardware available, GELI will run
cryptography on it automatically; if not, it starts dedicated
kernel thread and do crypto software work in there</li>
<li>supports many cryptographic algorithms (AES, Blowfish,
3DES)</li>
<li>is able to take key components from many sources at once
(user entered passphrase, random bits from a file, etc.)</li>
<li>allows to encrypt root partition</li>
<li>user will be asked for the passphrase before root file system
is mounted</li>
<li>uses "PKCS #5: Password-Based Cryptography Specification
Version 2.0" for user passphrase protection (optional)</li>
<li>allows to use two independent keys (e.g. "user key" and
"company key")</li>
<li>is fast</li>
<li>GELI does simple sector-to-sector encryption</li>
<li>allows to backup/restore Master Keys, so when user have to
quickly destroy keys, it is able to get the data back by
restoring keys from the backup</li>
<li>provider can be configured at attach time to automatically
detach on last close (so user don't have to remember to detach
after unmounting file system)</li>
<li>allows to attach provider with a random, one-time keys</li>
<li>useful for swap partitions and temporary file systems</li>
</ul>
</body>
<help>
<task>Code audit/review is more than welcome!</task>
</help>
</project>
<project cat='doc'>
<title>FreeBSD Dutch Documentation Project</title>
<contact>
<person>
<name>
<given>Remko</given>
<common>Lodder</common>
</name>
<email>remko@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.freebsd.org/doc/nl/books/handbook">FreeBSD
Dutch Handbook</url>
<url href="http://www.evilcoder.org/freebsd_html/">FreeBSD Dutch
Handbook preview</url>
<url href="http://www.evilcoder.org/content/section/6/39/">The
Project Page</url>
</links>
<body>
<p>The FreeBSD Dutch Documentation Project is a ongoing project in
translating the English documentation to the Dutch language.
Currently we have translated almost the entire handbook, and more
to come. If you want to help out by review the Dutch documents, or
you want to help translating the remainders of the handbook or
other documents, feel free to contact me at
<a href="mailto:remko@FreeBSD.org">remko@FreeBSD.org</a>
</p>
</body>
<help>
<task>Translate the English handbook, then review the Dutch
handbook</task>
<task>Translate the English FAQ, then review the Dutch FAQ</task>
<task>Translate the English Articles, then review the Dutch
Articles</task>
</help>
</project>
<project cat='proj'>
<title>FreeBSD Java Project</title>
<contact>
<person>
<name>
<given>Greg</given>
<common>Lewis</common>
</name>
<email>glewis@FreeBSD.org</email>
</person>
<person>
<name>
<given>Alexey</given>
<common>Zelkin</common>
</name>
<email>phantom@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/java/" />
</links>
<body>
<p>The FreeBSD Java Project released its initial support for JDK
1.5.0 with patch set 1 "Sabretooth" in January. The initial release
featured support for both FreeBSD 5.3/i386 and 5.3/amd64. Since
then preliminary support for FreeBSD 4.11/i386 has been added and
several bug fixes have been made. Updates in the coming months will
add support for the browser plug in and Java Web Start, which were
not in the initial release.</p>
</body>
<help>
<task>Volunteers to look into some serious problems with JDK 1.5.0
on FreeBSD 4.x</task>
</help>
</project>
<project cat='proj'>
<title>Common Address Redundancy Protocol - CARP</title>
<contact>
<person>
<name>
<given>Max</given>
<common>Laier</common>
</name>
<email>mlaier@FreeBSD.org</email>
</person>
</contact>
<contact>
<person>
<name>
<given>Gleb</given>
<common>Smirnoff</common>
</name>
<email>glebius@FreeBSD.org</email>
</person>
</contact>
<links>
<url
href="http://www.freebsd.org/cgi/man.cgi?query=carp&manpath=FreeBSD+6.0-current" />
<url href="http://people.freebsd.org/~mlaier/CARP/" />
</links>
<body>
<p>CARP is an alternative to VRRP. In contrast to VRRP it has full
support for IPv6 and uses crypto to protect the advertisements. It
was developed by OpenBSD due to concerns that the HSRP patent might
cover VRRP and CISCO might defend its patent. CARP has, since then,
improved a lot over VRRP.</p>
<p>CARP has been committed to HEAD and MFCed to RELENG_5. It will
be available in upcoming 5.4-RELEASE.</p>
<p>Big thanks to all users who provided testing and reported bugs
to Max and Gleb. Daniel Seuffert has donated hardware to Max for
this project. Gleb's work was sponsored by
<a href="http://www.rambler.ru">Rambler</a>
.</p>
</body>
<help>
<task>Improve vlan(4) support. Test ng_eiface(4).</task>
<task>Improve locking, consider removing interface layer.</task>
</help>
</project>
<project cat='net'>
<title>netgraph(4) status report</title>
<contact>
<person>
<name>
<given>Gleb</given>
<common>Smirnoff</common>
</name>
<email>glebius@FreeBSD.org</email>
</person>
</contact>
<links>
<url
href="http://www.freebsd.org/cgi/man.cgi?query=ng_netflow&manpath=FreeBSD+6.0-current">
ng_netflow(4)</url>
<url
href="http://www.freebsd.org/cgi/man.cgi?query=ng_ipfw&manpath=FreeBSD+6.0-current">
ng_ipfw(4)</url>
<url href="http://people.freebsd.org/~glebius/totest/ng_nat/">
ng_nat work in progress</url>
</links>
<body>
<p>This report covers period since August 2004 until April
2005.</p>
<p>New nodes. Two new nodes have been added to base FreeBSD
distribution. ng_netflow(4) node, which implements NetFlow version
5 accounting of IPv4 packets. ng_ipfw(4) node, which diverts
packets from ipfw(4) to netgraph(4) and back. A well known
ng_ipacct node has been added to ports tree.</p>
<p>SMP. Nodes, which need to allocate unique names have been
protected with mutex in RELENG_5, and subr_unit allocator in HEAD.
Nodes, which need to run periodical jobs were reworked to use
mpsafe ng_callout() API. ng_tty(4) node has been overhauled to be
compatible with debug.mpsafenet=1. NetGraph ISR and callout are now
declared MPSAFE in HEAD.</p>
<p>NetGraph flow control. Two nodes ng_ether(4) and ng_cisco(4)
have been improved to emit flow control messages to upstream node,
when state of link changes. New link failure detection method have
been introduced in ng_one2many(4) node - listening to these flow
control messages from downstream.</p>
</body>
<help>
<task>more SMP testing of many nodes</task>
<task>review locking of graph restructuring</task>
<task>ng_nat node - an in-kernel natd(8)</task>
<task>make ng_bridge(4) multithreaded</task>
</help>
</project>
<project cat='kern'>
<title>drm</title>
<contact>
<person>
<name>
<given>Eric</given>
<common>Anholt</common>
</name>
<email>anholt@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://r300.sourceforge.net/">ATI R300 DRI project</url>
</links>
<body>
<p>A DRM update was finally committed to -current on 2005-04-15,
after jhb@ did the necessary fix to vm_mmap. New development
drivers were added for mach64 and r300 (see URL for info). The
nearly-finished code for savage and i915 were also added, but left
disconnected from the build. However, the most visible change is
likely the support for texture tiling, color tiling, and HyperZ on
Radeons, which (with updated userland) likely provide a 50-75%
framerate increase in many applications.</p>
</body>
<help>
<task>Find someone with newbus knowledge to figure out why the i915
won't attach to drmsub0.</task>
<task>Finish porting the savage driver.</task>
<task>Integrate busdma code from Tonnerre (NetBSD).</task>
</help>
</project>
<project cat='kern'>
<title>Storage driver SMPng locking</title>
<contact>
<person>
<name>
<given>Scott</given>
<common>Long</common>
</name>
<email>scottl@FreeBSD.org</email>
</person>
</contact>
<links>
</links>
<body>
<p>Several storage drivers have been taken out from under the Giant
mutex in the past few months. Thanks to sponsorship from
<a href="http://www.freebsdsystems.com">FreeBSD Systems, Inc</a>
and
<a href="http://www.imp.ch">ImproWare, AG, Switzerland</a>
, the LSI MegaRAID (AMR) and IBM/Adaptec ServeRAID (IPS) drivers
have been locked. SMPng locking is a key step in improving the
performance of system drivers in FreeBSD 5.x and beyond, and both
of these drivers are showing the benefits of this. FreeBSD 5.4 will
contains these improvements when it is released.</p>
<p>Similar work is ongoing with the 3WARE Escalade (TWE) driver,
and preliminary patches have been made available to testers. I hope
to have this driver complete in time for the next FreeBSD
release.</p>
<p>Unfortunately, most benefits can only be gained from pure block
storage drivers such as the ones mentioned here due to the SCSI
subsystem in FreeBSD (CAM) not be locked itself at this time. It is
possible, however, to lock a CAM sub-driver and bring the driver's
interrupt handler out from under Giant for a partial gain. The Sun
FAS366 SCSI driver (ESP) operates like this. Volunteers to lock
other drivers or to tackle locking CAM are gladly accepted, so
please contact me if you are interested.</p>
</body>
</project>
<project cat='kern'>
<title>Filesystem journalling for UFS</title>
<contact>
<person>
<name>
<given>Scott</given>
<common>Long</common>
</name>
<email>scottl@FreeBSD.org</email>
</person>
</contact>
<links>
<url
href="http://repoman.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/scottl/ufsj" />
</links>
<body>
<p>It's time to bite the bullet and admit that fsck is no longer
scalable for modern storage capacities. While a healthy debate can
still be had on the merits and data integrity guarantees of
journalling vs. SoftUpdates, the fact that SoftUpdates still
requires a fsck to ensure consistency of the filesystem metadata
after an unclean shutdown means uptime is lost. While background
fsck is available, it saps system performance and stretched the
fsck time out to hours.</p>
<p>Journalling provides a way to record transactions that might not
have fully been written to disk before the system crashed, and then
quickly recover the system back to a consistent state by replaying
these transactions. It doesn't guarantee that no data will be lost,
but it does guarantee that the filesystem will be back to a
consistent state after the replay is performed. This contrasts to
SoftUpdates that re-arranges metadata updates so that
inconsistencies are minimized and easy to recover from, though
recovery still requires the traditional full filesystem scan.</p>
<p>Journalling is a key feature of many modern filesystems like
NTFS, XFS, JFS, ReiserFS, and Ext3, so the ground is well covered
and the risks for UFS/FFS are low. I'm aware that groups from CMU
and RPI have attempted similar work in the past, but unfortunately
the work is either very outdates, or I haven't had any luck in
contacting the groups. Is this absence, I've decided to work on
this project myself in hopes of having a functional prototype in
time for FreeBSD 6.0.</p>
<p>The approach is simple and journals full metadata blocks instead
of just deltas or high-level operations. This greatly simplifies
the replay code at the cost of requiring more disk space for the
journal and more work within the filesystem to identify discreet
update points. An important design consideration is whether to make
the journal data and code compatible with the UFS2 filesystem, or
to start a new UFS3 derivative. Since the latter presents a very
high barrier to adoption for most people, I'm going to try to make
it a compatible option for UFS2. This means that the journal blocks
will likely appear as an unlinked file to legacy filesystem and
fsck code, and will be treated as such. This will allow seamless
fallback to using fsck, though once the unlinked journal data
blocks are reclaimed by fsck, the user will have to take action to
re-create the journal file again.</p>
<p>One key piece of journalling is ensuring that each journal
transaction is fully written to disk before the associated metadata
blocks are written to the filesystem. I plan to adopt the buffer
'pinning' mechanism from Alexander Kabaev's XFS work to assist with
this. This will allow the journalling subsystem fine-grained
control over which blocks get flushed to disk by the buffer daemon
without having to further complicate the UFS/FFS code. One
consideration is how Softupdates falls into this and whether it is
mutually exclusive of journalling or if it can help provide
transaction ordering functionality to the journal. Research here is
on-going.</p>
<p>Some preliminary work can be found in Perforce in the
//depot/user/scottl/ufsj/... tree or at the URL provided. Hopefully
this will quickly accelerate.</p>
</body>
</project>
<project cat='kern'>
<title>Status Report for FreeBSD ATA driver project</title>
<contact>
<person>
<name>
<given>Søren</given>
<common>Schmidt</common>
</name>
<email>sos@FreeBSD.org</email>
</person>
</contact>
<body>
<p>ATA mkIII has been committed to -current after a couple of month
testing as patches post on -current and 5-stable. I will continue
to provide patches for 5-stable for those that need up-to-date ATA
support there.</p>
<p>Here a short rehash of what mkIII brings:</p>
<p>ATA is now fully modular so each part can be loaded/unloaded at
will to provided the wanted functionality.</p>
<p>Much improved SATA support that support hotplug events on
controllers that support it (Promise, SiS, nVidia so far) ie the
system will automagically detect when SATA devices come and go and
add/delete device entries etc.</p>
<p>Much improved ATA RAID support. The ata-raid driver has been
largely rewritten to take advantage of the features the improved
infrastructure provides, including composite ATA operations etc.
The rebuild functionality has been changed to rebuild on userland
reads, so a simple dd of the entire array will get it rebuild (what
atacontrol now does). This means that the resources used for this
can be better tailored to the actually usage pattern if needed. ATA
RAID now supports 10+ different RAID metadata formats, so most BIOS
defined ATA RAID arrays can be picked up and used. The number of
metadata formats that can be created from within FreeBSD is still
limited though and is not a high priority feature right now.</p>
<p>The lowlevel infrastructure of the ATA driver has been refined
even further to support "strange" chipsets much more easily and in
most case transparent to the higher levels. This to easy ports to
new platforms where ATA controllers doesn't necessarily have the
x86 legacy layout.</p>
<p>Lots of bug fixes and corrections all over the driver proper.
The rework of the infrastructure has revealed bugs and deficiencies
that has been fixed in the process of modulerising ATA and making
the infrastructure more generic, and hopefully easier to
understand.</p>
<p>The work continues to keep ATA on top of new chipsets and other
advancements in the ATA camp. SATA ATAPI support is in the works
and so are support for NCA/TCQ (tags). Donations of unsupported
hardware is the way to get it supported as I'm way out of my budget
for new hardware for the next decade or so according to my wife
:)</p>
</body>
<help>
<task>Lots of testing wanted, especially SATA and RAID
support</task>
</help>
</project>
<project cat='proj'>
<title>GSHSEC - GEOM class for handling shared secret</title>
<contact>
<person>
<name>
<given>Pawel Jakub</given>
<common>Dawidek</common>
</name>
<email>pjd@FreeBSD.org</email>
</person>
</contact>
<links>
<url
href="http://www.freebsd.org/cgi/man.cgi?query=gshsec&apropos=0&sektion=0&manpath=FreeBSD+6.0-current&format=html">
Manual page.</url>
</links>
<body>
<p>GSHSEC is a GEOM class used for handling shared secret data
between multiple GEOM providers. For every write request, SHSEC
class splits the data using XOR operation with random data, so N-1
providers gets just random data and one provider gets the data
XORed with the random data from the other providers. All of the
configured providers must be present in order to reveal the secret.
The class is already committed to HEAD and RELENG_5 branches.</p>
</body>
</project>
<project cat='kern'>
<title>ATAPI/CAM</title>
<contact>
<person>
<name>
<given>Thomas</given>
<common>Quinot</common>
</name>
<email>thomas@FreeBSD.org</email>
</person>
</contact>
<links>
</links>
<body>
<p>ATAPI/CAM integration with the new ATA (mkIII) framework is now
completed. ATAPI/CAM is now available as a loadable module
(atapicam.ko). It is also independent from the native ATAPI drivers
again, as was the case before mkIII.</p>
<p>Thanks to Scott Long and Søren Schmidt for their
participation in the integration work.</p>
</body>
</project>
<project cat='vendor'>
<title>twa driver</title>
<contact>
<person>
<name>
<given>Vinod</given>
<common>Kashyap</common>
</name>
<email>vkashyap at amcc.com</email>
</person>
</contact>
<links>
<url href="http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/twa/">
source code</url>
<url
href="http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/modules/twa/">
source code</url>
</links>
<body>
<p>A newly re-architected twa(4) driver was committed to 6 -CURRENT
on 04/12/2005. Highlights of this release are:</p>
<ol>
<li>The driver has been re-architected to use a "Common Layer"
(all tw_cl* files), which is a consolidation of all
OS-independent parts of the driver. The FreeBSD OS specific
portions of the driver go into an "OS Layer" (all tw_osl* files).
This re-architecture is to achieve better maintainability,
consistency of behavior across OS's, and better portability to
new OS's (drivers for new OS's can be written by just adding an
OS Layer that's specific to the OS, by complying to a "Common
Layer Programming Interface (CLPI)" API. If there's interest in
porting the 3ware driver to any other OS, you may contact ctchu
at amcc.com to get a copy of the CLPI specifications.</li>
<li>The driver takes advantage of multiple processors. It does
not need to be Giant protected anymore.</li>
<li>The driver has a new firmware image bundled, the new features
of which include Online Capacity Expansion and multi-lun support,
among others. More details about 3ware's 9.2 release can be found
here:
<a
href="http://www.3ware.com/download/Escalade9000Series/9.2/9.2_Release_Notes_Web.pdf">
http://www.3ware.com/download/Escalade9000Series/9.2/9.2_Release_Notes_Web.pdf</a>
</li>
</ol>
</body>
</project>
<project cat='net'>
<title>IPv6 Support for IPFW</title>
<contact>
<person>
<name>
<given>Brooks</given>
<common>Davis</common>
</name>
<email>brooks@FreeBSD.org</email>
</person>
</contact>
<links>
<url
href="http://lists.freebsd.org/pipermail/cvs-all/2005-April/116671.html" />
</links>
<body>
<p>In April 18th, I committed support for IPv6 to IPFW. This
support was written by two student of Luigi's, Mariano Tortoriello
and Raffaele De Lorenzo. I updated it to use PFIL_HOOKS and fixed a
few minor issues. As of this commit, IP6FW should be considered
deprecated in favor of IPFW. It should be possible to MFC this
change to 5.x, but that is not currently planned.</p>
</body>
<help>
<task>Testing.</task>
<task>IP6FW to IPFW migration guide.</task>
<task>Patches relative to 5-STABLE.</task>
</help>
</project>
<project cat='net'>
<title>Removable interface improvements.</title>
<contact>
<person>
<name>
<given>Brooks</given>
<common>Davis</common>
</name>
<email>brooks@FreeBSD.org</email>
</person>
</contact>
<links>
<url
href="http://people.freebsd.org/~brooks/pubs/eurobsdcon2004/" />
<url href="http://www.freebsd.org/projects/dingo/" />
</links>
<body>
<p>This project is an attempt to clean up handling of network
interfaces in order to allow interfaces to be removed reliably.
Current problems include panics if Dummynet is delaying packets to
an interface when it is removed.</p>
<p>I am currently working to remove struct ifnet's from device
driver structures to allow them to be managed properly upon device
removal. I believe I have removed all known instances of casting a
struct ifnet pointer to something else (except that that are just
magic values and not real struct ifnets.) I will begin committing
these changes to the tree shortly and will then add a new function
if_alloc() that will allocate struct ifnets. if_detach() will be
modified to destroy them.</p>
</body>
</project>
<project cat='kern'>
<title>cpufreq</title>
<contact>
<person>
<name>
<given>Nate</given>
<common>Lawson</common>
</name>
<email>njl</email>
</person>
</contact>
<links>
<url
href="http://www.freebsd.org/cgi/man.cgi?query=cpufreq&manpath=FreeBSD+6.0-current&format=html">
cpufreq man page</url>
</links>
<body>
<p>The cpufreq project was committed to 6-CURRENT in early February
and has undergone bugfixes and updates. It will soon be MFCd to
5-STABLE.</p>
<p>The cpufreq driver provides a unified kernel and user interface
to CPU frequency control drivers. It combines multiple drivers
offering different settings into a single interface of all possible
levels. Users can access this interface directly via sysctl(8), by
indicating to power_profile that it should switch settings when the
AC line state changes, or by using powerd(8).</p>
<p>For example, an absolute driver offering frequencies of 1000 Mhz
and 750 Mhz combined with a relative driver offering settings of
100% and 50% would result in cpufreq providing levels of 1000, 750,
500, and 375 Mhz.</p>
<p>Colin Percival helped with powerd(8), which provides automatic
control of CPU frequencies. The adaptive mode is especially
interesting since it attempts to respond to changes in system load
while reducing power consumption.</p>
<p>Current hardware drivers include acpi_perf (ACPI CPU performance
states), est (Intel Enhanced SpeedStep for Pentium-M), ichss
(Intel's original SpeedStep for ICH), and powernow (AMD Powernow!
K7 and K8 support). Other drivers for relative hardware include
acpi_throttle (ACPI CPU throttling) and p4tcc (Pentium 4 Thermal
Control Circuitry)</p>
<p>Thanks to Bruno Ducrot for the powernow driver, Colin Percival
for the est driver, and the many testers who have sent in
feedback.</p>
</body>
<help>
<task>We'd appreciate someone with a Transmeta CPU converting the
existing longrun driver to the cpufreq framework. It would also be
good if someone wrote a VIA Longhaul driver. See the Linux
arch/i386/kernel/cpu/cpufreq directory for examples.</task>
<task>Various other architectures, including ARM, have CPU power
control that could be implemented as a cpufreq driver.</task>
<task>The powerd(8) algorithm is rather simple and we'd appreciate
more help in testing it and alternative algorithms with various
workloads. The -v flag causes powerd to report frequency
transitions and print a summary of total energy used upon
termination. This should help testers profile their
algorithms.</task>
</help>
</project>
<project cat='net'>
<title>Move ARP out of routing table</title>
<contact>
<person>
<name>
<given>Qing</given>
<common>Li</common>
</name>
<email>qingli@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://people.freebsd.org/~qingli/">containing the
patch</url>
</links>
<body>
<p>I have finished the basic functionality for both IPv4 and IPv6.
The userland utilities ("arp" and "ndp") have been updated. I have
tested the changes with "make buildworld". I have been testing the
new code in a production environment and things appear to be
stable. Gleb Smirnoff (glebius@FreeBSD.org) has provided review
comments and I have incorporated these feedback into the patch. I
have discussed the IPv6 changes with two of the core KAME
developers during the last IETF meeting in March 2005. They
indicated that these changes may result in divergence from the KAME
project but that is not necessarily a bad thing.</p>
</body>
<help>
<task>I am waiting for review feedback from my mentor Andre. I need
locking experts to help me fix my giant-lock shortcut. I am hoping
to send out the code for wider review soon.</task>
</help>
</project>
<project cat='net'>
<title>Support for telephone hardware (aka Zaptel)</title>
<contact>
<person>
<name>
<given>Maxim</given>
<common>Sobolev</common>
</name>
<email>sobomax@FreeBSD.org</email>
</person>
<person>
<name>
<given>Oleksandr</given>
<common>Tymoshenko</common>
</name>
<email>gonzo@pbxpress.com</email>
</person>
<person>
<name>
<given>Max</given>
<common>Khon</common>
</name>
<email>fjoe@FreeBSD.org</email>
</person>
</contact>
<links>
<url
href="http://www.digium.com/index.php?menu=hardware_products" />
</links>
<body>
<p>During the last 2 months lot of progress has been made. Existing
support for TDM400 (FXO/FXS) has been significantly improved.
Drivers for PRI and BRI cards have been added and now should be
considered beta-quality.</p>
</body>
<help>
<task>More testing of PRI/BRI drivers.</task>
<task>Add support for channelized DS3 card(s).</task>
</help>
</project>
<project cat='ports'>
<title>FreshPorts</title>
<contact>
<person>
<name>
<given>Dan</given>
<common>Langille</common>
</name>
<email>dan@langille.org</email>
</person>
</contact>
<links>
<url href="http://www.freshports.org/">FreshPorts</url>
</links>
<body>
<p>This is the first status report for FreshPorts. FreshPorts
started in early 2000 and now contains over 170,000 commits.
FreshPorts is primarily concerned with port commits, but actually
processes and records all commits to the FreeBSD source tree. Its
sister site,
<a href="http://www.freshsource.org/">FreshSource</a>
uses the same database as FreshPorts but has a wider reporting
scope. In recent months, FreshPorts has been enhanced to process
and include
<a href="http://www.vuxml.org/freebsd/">VuXML</a>
information. In addition, RESTRICTED and NO_CDROM have been added
to list of things that FreshPorts keeps track of. For unmaintained
ports, we recently added this message:
<p>
<em>There is no maintainer for this port.
<br />
Any concerns regarding this port should be directed to the
FreeBSD Ports mailing list via ports@FreeBSD.org</em>
</p>
FreshPorts, with direct and indirect support from the FreeBSD
community, continues to evolve and to provide a great tool for
users and developers alike.</p>
</body>
<help>
<task>Provide a copy/paste method for updating watch lists</task>
<task>improvement of query times for "People watching this port,
also watch"</task>
<task>pagination of commits within a port</task>
<task>pagination of watch lists</task>
<task>create an RSS feed for individual watch lists</task>
</help>
</project>
<project cat='misc'>
<title>BSDCan</title>
<contact>
<person>
<name>
<given>Dan</given>
<common>Langille</common>
</name>
<email>dan@langille.org</email>
</person>
</contact>
<links>
<url href="http://www.bsdcan.org/" />
</links>
<body>
<p>BSDCan made a strong debut in
<a href="http://www.bsdcan.org/2004/">2004</a>
. The favorable reception gave us a strong incentive for
<a href="http://www.bsdcan.org/2005/">2005</a>
. We have been rewarded with a very interesting
<a href="http://www.bsdcan.org/2005/schedule.php">program</a>
and a higher rate of registrations. Percentage-wise, we have more
Europeans than last year as they have decided that the trip across
the Atlantic is worth taking. We know they won't be disappointed.
See you at BSDCan 2005!</p>
</body>
<help>
<task>volunteers needed for the conference</task>
</help>
</project>
<project cat='ports'>
<title>Ports Collection</title>
<contact>
<person>
<name>
<given>Mark</given>
<common>Linimon</common>
</name>
<email>linimon@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.freebsd.org/ports/">The FreeBSD ports
collection</url>
<url href="http://portsmon.firepipe.net/index.html">FreeBSD ports
monitoring system</url>
<url href="http://www.freebsd.org/portmgr/index.html">The FreeBSD
Ports Management Team</url>
</links>
<body>
<p>As this report was being written, the 5.4 release was
ongoing.</p>
<p>A new charter for the Ports Management (portmgr) team was
approved by core and has been posted at the URL above. In addition,
two other new pages describe the policies of the team, and the
range of QA activities both during and between releases.</p>
<p>Due to being absent from email discussions for some time, Oliver
Eikemeier (eik) was moved to non-voting status on portmgr.</p>
<p>We have added several new and very active committers recently;
this is helping us to keep the PR count low even with the large
numbers of new ports that have been added.</p>
<p>Several more iterations of infrastructure changes have been
tested on the cluster and committed; see /usr/ports/CHANGES for
details.</p>
<p>Updates have occurred to x.org, GNOME, KDE, and perl.</p>
<p>There have been some updates to the Porter's Handbook, but more
sections are still in need of updates to include recent changes in
practices.</p>
<p>The ports collection now contains almost 12,750 ports.</p>
</body>
<help>
<task>Further progress has been made in cracking down on ports that
install files outside the approved directories and/or do not
deinstall cleanly (see "Extra files not listed in PLIST" on
<a href="http://pointyhat.freebsd.org/errorlogs/">pointyhat</a>
) and this will remain a focus area. We appreciate everyone who has
sent in PRs or committed fixes.</task>
<task>Demand for new features and revisions for bsd.port.mk is
still very high and the portmgr team is trying to work through them
all.</task>
<task>We still have a large number of PRs that have been assigned
to committers for some time (in fact, they constitute the
majority). One goal of portmgr in the coming months is to try to
reduce this number, and we would like to ask our committers to help
us out as much as possible.</task>
</help>
</project>
<project cat='arch'>
<title>PowerPC Port</title>
<contact>
<person>
<name>
<given>Peter</given>
<common>Grehan</common>
</name>
<email>grehan@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Progress continues. X.Org 6.8.1 server has been up and running
on a number of different Macs, and the work is being merged into
6.8.2. There have been successful installs on Mac Minis</p>
</body>
</project>
<project cat='vendor'>
<title>OpenBSD packet filter - pf</title>
<contact>
<person>
<name>
<given>Max</given>
<common>Laier</common>
</name>
<email>mlaier@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://pf4freebsd.love2party.net/">pf4FreeBSD
Homepage</url>
<url href="http://people.freebsd.org/~mlaier/pf37/">pf 3.7 patches</url>
</links>
<body>
<p>OpenBSD is about to release
<a href="http://www.openbsd.org/37.html">version 3.7</a>
. There are
<a href="http://people.freebsd.org/~mlaier/pf37/">patches</a>
available to catch up with the development done in OpenBSD 3.6 and
3.7. These patches are in an early stage, but ready for testing,
please help.</p>
<p>Otherwise there was not much activity on pf, as it already is
quite stable. Other work, such as CARP and if_bridge are having
impact on pf in FreeBSD however, please see the respective
reports.</p>
</body>
<help>
<task>Alpha/Betatesting of the 3.7 import</task>
<task>Testing with if_bridge</task>
</help>
</project>
<project cat='bin'>
<title>libthread</title>
<contact>
<person>
<name>
<given>David</given>
<common>Xu</common>
</name>
<email>davidxu@FreeBSD.org</email>
</person>
</contact>
<links>
</links>
<body>
<p>libthread is a pure 1:1 threading library, it had stayed in my
perforce branch for a long time, recent it was imported into source
tree and replaced libthr. The purpose of the work is to improve 1:1
threading on FreeBSD, the library is designed in mind that simplest
is best, currently it can run almost all of the applications
libpthread can run, but gives you better SMP performance. The
library size is smaller than libpthread.</p>
<p>Currently it supports i386, AMD64, sparc64 and ia64 and may
support alpha, powerpc and arm. I didn't do many tests on sparc64
and ia64, I only tested it on FreeBSD cluster machines. For i386, I
always used LDT, but know that Peter committed GDT code, and now
there is no 8191 threads limitation anymore.</p>
<p>libthread_db was updated to support debugging the new libthr. It
is an assistant library used by gdb to debug threaded process, that
understands internal detail of thread libraries. I have improved it
a bit to support event reports for libthr, currently it can report
thread creation and death events. That means a thread that was
created and died will be reported to the user regardless if you are
tracking it or not.</p>
</body>
<help>
<task>I am working on thread creation performance, currently it
needs considerable number of libc functions and syscalls to create
a thread, I would like to introduce a syscall to create a thread in
atomically. That means one syscall will setup thread entry, tls, and
signal mask and PTHREAD_SCOPE_PROCESS/SYSTEM; in future maybe even
CPU affinity masks, when userland entry code is executed, the
thread is already fully setup.</task>
<task>Process shareable synchronization objects. In Current FreeBSD
does not support this specification. The idea about the shareable
mutex and others is like other systems did, one can use mmap() to
create a shared memory page, and put a pthread synchronization
object in the page, multiple processes use the shared object to
control resource access. I am not working on it, if someone is
interested, please let me know.</task>
</help>
</project>
<project cat='kern'>
<title>Coverity Code Analysis</title>
<contact>
<person>
<name>
<given>Sam</given>
<common>Leffler</common>
</name>
<email>sam@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.coverity.com/" />
</links>
<body>
<p>There has been an ongoing effort to review the kernel source
code using Coverity's source code analysis tools
(http://www.coverity.com). These tools check for a variety of
problems such as null pointer dereference, use-after-free of
allocated variables, invalid array references, etc. This work is a
joint project between FreeBSD and Coverity.</p>
<p>Two passes have been completed over the 6-current kernel source
code base and all significant problems have been corrected. These
runs were done in February and March of this year. A few reports of
minor problems await response from outside groups and will be
resolved in time for the first 6.x release. Another analysis run
over the kernel will happen soon. We are looking for a way to use
these tools on a regular basis as they have been helpful in
improving the code base.</p>
<p>Thanks to Coverity for their help and especially Ted Unangst.
Several developers have been especially helpful in resolving
reports: Poul-Henning Kamp, David Schultz, Pawel Jakub Dawidek,
George V. Neville-Neil, and Matthew Dodd.</p>
</body>
</project>
<project cat='net'>
<title>Wireless Networking Support</title>
<contact>
<person>
<name>
<given>Sam</given>
<common>Leffler</common>
</name>
<email>sam@FreeBSD.org</email>
</person>
</contact>
<links>
</links>
<body>
<p>Several new drivers by by Damien Bergamini were brought into the
tree: iwi, ipw, ral, and ural.</p>
<p>WPA-PSK support for the ndis driver was contributed by Arvind
Srinivasa.</p>
<p>A new tx rate control algorithm for the ath driver was
contributed by John Bicket. It will become the default algorithm
shortly.</p>
<p>Work on multi-bss support is going on outside the cvs tree. A
presentation on this work will be given at BSDCan 2005 and the
slides for the talk will be made available after.</p>
</body>
<help>
<task>Drivers other than ath and ndis need updates to support the
new security protocols.</task>
<task>hostapd needs work to support the IAPP and 802.11i
preauthentication protocols (these are simple conversions of
existing Linux code).</task>
<task>The OpenBSD dhclient program has been ported but needs a
developer that will maintain it once it is brought into cvs.</task>
</help>
</project>
<project cat='kern'>
<title>Many subdirs for UFS</title>
<contact>
<person>
<name>
<given>David</given>
<common>Malone</common>
</name>
<email>dwmalone@FreeBSD.org</email>
</person>
</contact>
<links>
<url
href="http://groups-beta.google.com/group/muc.lists.freebsd.fs/browse_frm/thread/a36d1143d695287e/40cad00cf2c0823b?hl=en#40cad00cf2c0823b">
Thread on freebsd-fs</url>
</links>
<body>
<p>I'm currently looking at the limit on the number of
subdirectories a directory can have in UFS. There is currently a
limit of 32K subdirectories because of the 16 bit link count field
in both struct stat and the on-disk inode format. The thread above
shows that dirhash provides acceptable performance for directories
with 100k subdirectories using a prototype patch. Two options for
allowing many subdirectories seem to exist: changing the link
counting scheme for directories and expanding the link count field.
The prototype patch implements the first scheme and there are plans
to investigate the second scheme (which may require an ABI
change).</p>
</body>
</project>
<project cat='misc'>
<title>IMUNES - a FreeBSD based kernel-level network topology
emulator</title>
<contact>
<person>
<name>
<given>Miljenko</given>
<common>Mikuc</common>
</name>
<email>miljenko@tel.fer.hr</email>
</person>
<person>
<name>
<given>Marko</given>
<common>Zec</common>
</name>
<email>zec@tel.fer.hr</email>
</person>
</contact>
<links>
<url href="http://www.imunes.net/" />
</links>
<body>
<p>IMUNES is a scalable kernel-level network topology emulator
based on FreeBSD. In IMUNES each virtual node operates on its
private instance of network stack state variables, such as routing
tables, interface addresses, sockets, ipfw rules etc. Most if not
all existing FreeBSD application binaries, including routing
protocol daemons such as quagga or XORP, can run unmodified within
the context of virtual nodes with no noticeable performance
penalty. Complex network topologies can be constructed by
connecting the virtual nodes through netgraph-based link-layer
paths. A GUI tool allows for simple and intuitive network topology
specification, deployment and management. The current version of
IMUNES is based on FreeBSD 4.11-RELEASE and supports IPv4.</p>
</body>
</project>
<project cat='arch'>
<title>XenFreeBSD - FreeBSD on Xen</title>
<contact>
<person>
<name>
<given>Kip</given>
<common>Macy</common>
</name>
<email>kmacy@fsmware.com</email>
</person>
</contact>
<links>
<url href="http://www.cl.cam.ac.uk/Research/SRG/netos/xen/">Xen
project page</url>
<url href="http://xen.bkbits.net/">Xen changeset logs</url>
</links>
<body>
<p>FreeBSD 5.3 runs on the stable and the development branches of
xen and is now checked into both trees. Over the next couple of
weeks I will be adding improvements for better batching of page
table updates and SMP support.</p>
</body>
<help>
<task>FreeBSD support for running as Domain 0, i.e. running as the
hosting operating system.</task>
<task>FreeBSD support for VM checkpoint and migration.</task>
</help>
</project>
<project cat='net'>
<title>Dingo</title>
<contact>
<person>
<name>
<given>George</given>
<common>Neville-Neil</common>
</name>
<email>gnn@neville-neil.com</email>
</person>
</contact>
<links>
<url href="http://people.freebsd.org/~gnn/Dingo/notebook/60.html">
Project page (out of date)</url>
<url href="http://zoo.unixdaemons.com/index.php?blog=7">Blog
covering test framework</url>
</links>
<body>
<p>On the protocol conformance tool I have finally made some
progress getting a scriptable packet library using libnet, and
SWIG. This will hopefully become a port that can then be used to do
conformance testing on protocol stack changes. Qing Li has
separately taken up the ARP rewrite and that will be taken out of
the Dingo project pages.</p>
</body>
<help>
<task>Many :-)</task>
</help>
</project>
<project cat='kern'>
<title>Interrupt Latency</title>
<contact>
<person>
<name>
<given>Warner</given>
<common>Losh</common>
</name>
<email>imp@FreeBSD.org</email>
</person>
</contact>
<links>
</links>
<body>
<p>I've setup a test system to measure interrupt latency on FreeBSD
5.3 and current. So far I've measured the baseline latency for a
300MHz embedded cyrix based single board computer. I've tried a
number of different strategies to optimize the interrupt path. Most
of these strategies resulted in some improvement of the time it
takes to get from the start of the interrupt servicing to the
driver's ISR. These improvements turned out to be about 1-2% of the
processing times on this single board computer, but a wash on
faster machines. However, the time between when the interrupt
should happen, and when FreeBSD starts to service the interrupt is
the dominant factor in these measurements. Despite the fact that
these are fast interrupt handlers (so the scheduler is out of the
loop), I routinely see average latencies of 18us, with large
variations (on the order of 5us standard deviation).</p>
</body>
<help>
<task>I need to measure the latencies with 4.x and current to
characterize the differences more precisely. I'm especially
interested in the effects on interrupt latency that the elimination
of mixed mode will cause.</task>
<task>I need to characterize different parts of our ISR routines to
see if some of the variation I've seen so far can be reduced by
improved coding techniques.</task>
<task>I need to re-run my tests with 5.4 and summarize my results
in a paper.</task>
</help>
</project>
<project cat='kern'>
<title>Infrastructure Cleanup</title>
<contact>
<person>
<name>
<given>Warner</given>
<common>Losh</common>
</name>
<email>imp@FreeBSD.org</email>
</person>
<person>
<name>
<given>Takahashi</given>
<common>Yoshihiro</common>
</name>
<email>nyan@FreeBSD.org</email>
</person>
</contact>
<links>
</links>
<body>
<p>Unglamorous cleanup of the code base continues. The focus of
recent efforts have been to reduce the number of machine #ifdefs
that are in the machine independent code. In addition, we're also
trying to increase code sharing between pc98 and i386 ports and
reduce the number of #ifdef PC98 instances in the tree.</p>
<p>In addition, a number of cleanup tasks are underway for
different parts of the kernel that are more complicated than
necessary. Recently, the pccard code's allocation routines were
simplified to reassign ownership of resources more directly than
before. The search is on for other areas that can benefit from
cleanup.</p>
</body>
<help>
<task>On pc98, there's no such thing as an ISA bus. It is desirable
to move to having cbus appear in the probe messages. This would
also allow for additional segregation of pc98 specific code in the
drivers and eliminate many ifdefs. Ideally, isa and cbus would
share a common newbus ancestor class so their similarities can be
exploited (they both have PNPBIOS enumeration methods, for
example).</task>
<task>cbus devices can have complicated resources. There's support
for vectors of resources. Yet there's no support for populating a
vector of resources from the plug and play information. Doing so
would help the complex world of pc98 a lot, and the odd edge cases
in i386 (floppy, ata) a little.</task>
<task>The hints mechanism provides a way to associate hardware with
drivers and resource that would otherwise be completely unknown to
the system. A refinement in the hints mechanism to allow matching
of driver instances to resources is desirable. This would allow one
to hardwire sio0 to 0x2f8, even when the serial device in the plug
and play resource list (or acpi resource list) is listed second. A
further refinement could also be wiring sio0 to "port B" as defined
by acpi or some other enumeration method. Chances are good that
these seemingly related concepts may need separate implementations
due to the decision points for unit assignment.</task>
<task>Pccard, cardbus and usb probe their devices after interrupts
are enabled. It would be desirable to hook into new kernel APIs to
allow the mounting of root to be put off until those systems know
that they are done with their initial probe of the devices present
at boot.</task>
</help>
</project>
<project cat='misc'>
<title>FreeBSD Security Officer and Security Team</title>
<contact>
<person>
<name>
<given>Security</given>
<common>Officer</common>
</name>
<email>security-officer@FreeBSD.org</email>
</person>
<person>
<name>
<given>Security</given>
<common>Team</common>
</name>
<email>security-team@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.freebsd.org/security/" />
<url
href="http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/staff-listing.html#STAFF-SECTEAM" />
<url href="http://vuxml.freebsd.org/" />
</links>
<body>
<p>In January 2005, Warner Losh (Security Officer Emeritus) stepped
down from the FreeBSD Security Team in order to better devote his
time to other projects. In March, Colin Percival was named as a
second Deputy Security Officer, joining Dag-Erling Smørgrav in
that position. The current Security Team membership is published on
the web site.</p>
<p>So far in 2005, four security advisories have been issued
concerning problems in the base system of FreeBSD, three of which
were specific to FreeBSD. The Vulnerabilities and Exposures Markup
Language (VuXML) document has continued to be updated by the
Security Team and the Ports Committers documenting new
vulnerabilities in the FreeBSD Ports Collection. As of April 17,
127 entries have been added in 2005 bringing the FreeBSD VuXML file
up to a total of 422 entries.</p>
<p>In the past months both the
<a href="http://vuxml.FreeBSD.org/">VuXML web site</a>
and the
<a href="http://www.FreshPorts.org/">FreshPorts</a>
VuXML integration have been improved. The VuXML web site has had a
face lift and, among other things, each package now has a separate
web page which lists all documented vulnerabilities for the
particular package.
<a href="http://cve.mitre.org/">CVE</a>
information is now also included directly on the VuXML web
site.</p>
<p>Finally, the first few months of 2005 also saw FreeBSD 4.8 --
the first release to be offered "extended support" -- reach its
designated End of Life. The currently supported releases are
FreeBSD 4.10, 4.11, and 5.3.</p>
</body>
</project>
<project cat='proj'>
<title>FreeBSD Release Engineering</title>
<contact>
<person>
<name>
<given>RE</given>
<common>Team</common>
</name>
<email>re@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.freebsd.org/releng" />
</links>
<body>
<p>FreeBSD 4.11, the final formal release of the 4.x series, was
released on 25 Jan 2005. Many thanks to the all of the developers
and users over the past 5 years who made it successful. While no
more releases are planned, the security team will continue to
support it through security update patches until 2007. Developers
are also free to commit bug fixes and low-risk features to the
RELENG_4 branch for the foreseeable future.</p>
<p>FreeBSD 5.4 is going through its final release candidate stages
and is expected to be released in late April. Its focus is mostly
bug fixes and minor feature and performance improvements, so it is
an excellent target for those looking to upgrade from previous
versions or to give FreeBSD a try for the first time. FreeBSD 5.5
will be release in about 4-6 months after 5.4.</p>
<p>FreeBSD 6.0 is rapidly approaching also. In contrast to FreeBSD
5.0, the goal is to take a more incremental approach to major
changes, and not wait for years to get as many features in as
possible. FreeBSD 6.0 will largely be an evolutionary change from
the 5.x series, with the largest changes centered around
multi-threading and streamlining the filesystem and device layers.
Feature freeze and code freeze for 6.0 are coming up in May and
June, and we hope to have 6.0 stable and ready for release in July
or August.</p>
<p>The release engineering team has also started doing monthly
informal snapshots of the 6-CURRENT and 5-STABLE trees. These are
intended to increase the exposure of new features and get more
users involved in testing and providing feedback. Snapshots can
be found at <a href="http://www.freebsd.org/snapshots">
http://www.freebsd.org/snapshots</a>.</p>
</body>
</project>
<project cat='net'>
<title>New Wireless Drivers</title>
<contact>
<person>
<name>
<given>Damien</given>
<common>Bergamini</common>
</name>
<email>damien@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://ipw2100.sourceforge.net/firmware.php?fid=4" />
<url href="http://ralink.rapla.net/" />
</links>
<body>
<p>Four new wireless drivers were imported:</p>
<p>
<em>ipw</em>
: driver for Intel PRO/Wireless 2100 adapters (MiniPCI).
<br />
<em>iwi</em>
: driver for Intel PRO/Wireless 2200BG/2225BG/2915ABG adapters (PCI
or MiniPCI).
<br />
<em>ral</em>
: driver for Ralink RT2500 wireless adapters (PCI or CardBus).
<br />
<em>ural</em>
: driver for Ralink RT2500USB wireless USB 2.0 adapters.</p>
<p>The ipw and iwi drivers require firmwares to operate.
<br />
These firmwares can't be redistributed with the base system due to
license restrictions.
<br />
See firmware licensing terms here:
<a href="http://ipw2100.sourceforge.net/firmware.php?fid=4">
http://ipw2100.sourceforge.net/firmware.php?fid=4</a>
.
<br />
</p>
<p>Ports which include the firmware images as well as the firmware
loader are being worked on.
<br />
A list of adapters supported by ral and ural can be found here:
<a href="http://ralink.rapla.net/">http://ralink.rapla.net/</a>
.</p>
</body>
<help>
<task>Create ports for ipw and iwi firmwares.</task>
<task>Add IBSS support to iwi.</task>
<task>Add WPA (802.11i) support to ipw and iwi.</task>
<task>Add hardware encryption (WEP, TKIP and CCMP) support in ral
and ural.</task>
<task>Add automatic rate adaptation support to ural.</task>
</help>
</project>
</report>
|
