aboutsummaryrefslogtreecommitdiff
path: root/en_US.ISO8859-1/htdocs/news/status/report-2020-10-2020-12.xml
blob: 8d8c3e7bac2ab5026865137da7b8efb6909bde0d (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
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
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE report PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for
  Status Report//EN"
  "http://www.FreeBSD.org/XML/share/xml/statusreport.dtd" >

<!-- $FreeBSD$ -->

<!--
     Variables to replace:
     10     - report month start
     12      - report month end
     2020      - report year
     %%NUM%%       - report issue (first, second, third, fourth)
     %%STARTNEXT%% - report month start
     %%STOPNEXT%%  - report month end
     %%YEARNEXT%%  - next report due year (if different than 2020)
     %%DUENEXT%%   - next report due date (i.e., June 6)
-->

<report>
  <date>
    <month>10-12</month>

    <year>2020</year>
  </date>

  <section>
    <title>Introduction</title>
<p>This report covers FreeBSD related projects for the period between
October and December, and is the fourth of four planned reports for 2020.
</p>
<p>This quarter had quite a lot of work done, including but certainly not
limited to, in areas relating to everything from multiple architectures
such as x86, aarch64, riscv, and ppc64 for both base and ports, over kernel
changes such as vectored aio, routing lookups and multipathing, an
alternative random(4) implementation, zstd integration for kernel
dumps, log compression, zfs and preparations for pkg(8), along with
wifi changes, changes to the toolchain like the new elfctl utility,
and all the way to big changes like the git migration and moving the
documentation from DocBook to Hugo/AsciiDoctor, as well as many other
things too numerous to mention in an introduction.
</p>
<p>This report with 42 entries, which don't hold the answer to life, the
universe and everything, couldn't have happened without all the people
doing the work also writing an entry for the report, so the quarterly
team would like to thank them, as otherwise, we wouldn't have anything
to do.
</p>
<p>Please note that the deadline for submissions covering the period
between January and March is March 31st.
</p>
<p>We hope you'll enjoy reading as much as we enjoyed compiling it.<br/>
Daniel Ebdrup Jensen, on behalf of the quarterly team.
</p>  </section>
<project cat='team'>
<title>FreeBSD Foundation</title>

<contact>
<person>
<name>Deb Goodkin</name>
<email>deb@FreeBSDFoundation.org</email>
</person>
</contact>

<body><p>The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to
supporting and promoting the FreeBSD Project and community worldwide.  Funding
comes from individual and corporate donations and is used to fund and manage
software development projects, conferences and developer summits, and provide
travel grants to FreeBSD contributors.  The Foundation purchases and supports
hardware to improve and maintain FreeBSD infrastructure and provides resources
to improve security, quality assurance, and release engineering efforts;
publishes marketing material to promote, educate, and advocate for the FreeBSD
Project; facilitates collaboration between commercial vendors and FreeBSD
developers; and finally, represents the FreeBSD Project in executing contracts,
license agreements, and other legal arrangements that require a recognized
legal entity.
</p>
<p>Here are some highlights of what we did to help FreeBSD last quarter:
</p>
<h3>COVID-19 Impact to the Foundation</h3>

<p>Like most organizations, we transitioned all of our staff to work from home.
We also put a temporary ban on travel for staff members, which didn't affect
our output too much, since most conferences went virtual.  We continued
supporting the community and Project, even though some of our work and
responses may have been delayed because of changes in some of our priorities
and the impact of limited childcare for a few of our staff members.
</p>
<h3>Partnerships and Commercial User Support</h3>

<p>We help facilitate collaboration between commercial users and FreeBSD
developers.  We also meet with companies to discuss their needs and bring that
information back to the Project.  Not surprisingly, the stay at home orders,
combined with our company ban on travel during Q4 made in-person meetings
non-existent.  However, the team was able to continue meeting with our partners
and commercial users virtually.  These meetings help us understand some of the
applications where FreeBSD is used.
</p>
<p>An event we help plan and organize, that helps with vendor/developer
engagement, is the annual Bay Area Vendor Summit.  We weren't going to let a
pandemic stop us from holding this invaluable yearly event, so we went virtual!
From the feedback we received from the vendor community on how we should run
this, so it would be beneficial for them, we decided to hold this over 3 half
days in November.  One unexpected result was that more commercial users from
around the world attended.  Since a Vendor/Developer Summit is typically
invitation only, we opened this up to FreeBSD contributors from around the
world to watch the livestream.  Because of the success and excitement of this
event, we are planning to hold another one around June or July.
</p>
<h3>Fundraising Efforts</h3>

<p>We want to take a moment to say thank you to all the individuals and
corporations that stepped up to help fund our efforts last year.  As of this
writing, we raised $1,235,926, and will have the final tally by mid-January.
The companies that gave generous financial contributions include Arm, NetApp,
Netflix, Juniper Networks, Beckhoff, VMware, Stormshield, Tarsnap, and Google.
We also want to say thank you to the Koum Family Foundation for awarding us a
large grant, and to the employees of Nginx who also made generous financial
contributions.
</p>
<p>We truly appreciate these large contributions, which makes the most impact on
how much we can contribute back to the Project.  However, it's the individual
donations that have the most meaning to us.  Those are the folks who are giving
because they trust we will invest their personal donations, whether large or
small, into improving the operating system and Project.  As stewards of your
donations, we want to thank you for your trust in us and your commitment to
making FreeBSD the best platform for products, education, research, computing,
and more.
</p>
<p>You'll find out how we used your donations for Q4 in our report, as well as in
individual reports throughout this status report.
</p>
<p>Though we know this is a Q4 status report, we are excited about our plans for
2021, including growing our software development team!  We'll be posting two
job descriptions for a Senior Software Developer and Project Coordinator soon.
</p>
<p>Please consider making a donation to help us continue and increase our support
for FreeBSD in 2021: <a href='https://www.FreeBSDfoundation.org/donate/'>https://www.FreeBSDfoundation.org/donate/</a>.
</p>
<p>We also have the Partnership Program, to provide more benefits for our larger
commercial donors.  Find out more information at
<a href='https://www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/'>https://www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/</a>
and share with your companies!
</p>
<h3>OS Improvements</h3>

<p>The Foundation provided many project grants over the last quarter, and you
can read about OpenZFS Zstd support, Linuxulator application compatibility
improvements, LLDB target support, test lab infrastructure, and WiFi projects
in other entries in this quarterly report.
</p>
<p>The Foundation hired six co-op students from the University of Waterloo during
the 2020 fall term, as well as one intern.  Former co-op student Tiger
returned, and new students Yang and Zac joined us for the first time.
</p>
<p>Tiger worked on improvements to the code-coverage guided kernel fuzzing tool
Syzkaller, adding new system call definitions so that Syzkaller can expand the
code it tests.  A number of FreeBSD kernel bug fixes have already resulted from
this work.  Tiger also contributed a number of improvements to the ELF Tool
Chain set of binary utilities, and worked on tooling to run tests from other
tool suites against ELF Tool Chain.
</p>
<p>Zac worked on an improvement to the pkg package management tool, investigating
and upstreaming patches for FreeBSD support in FreePBX, and investigating
compiler support for addressing the stack clash vulnerability.
</p>
<p>Yang investigated and fixed a compilation bug with the kernel's Skein-1024
assembly implementation (used by ZFS), and then a number of projects related to
Capsicum: applying Capsicum to sort(1), implementing a Capsicum service to
execute utilities, and finally working with developers of the Game of Trees
(got) version control system to adapt it for Capsicum support.
</p>
<p>Our intern Ka Ho focused on improving the desktop experience of the FreeBSD.
He fixed and improved many items of OBS (Open Broadcaster Software) on
FreeBSD, worked on FreeBSD native audio support on Firefox, adding a facility
that user-space audio programs could make use of to enumerate a list of audio
devices.  He also ported the fcitx5 input method framework.
</p>
<p>The five Foundation staff members continued contributions in 2020 in both
ongoing operational tasks (including the Git working group and security team)
and software development for a number of projects.
</p>
<p>Staff members responded to reported security vulnerabilities and release
errata, prepared patches, and participated in the security advisory process.
We also worked on proactive security vulnerability mitigations.  Syzkaller
also provided many reports of kernel issues that resulted in
Foundation-sponsored bug fixes.  We worked on several issues relating to
FreeBSD/arm64 to move it along the path of being a Tier-1 architecture.
</p>
<p>We participated in code reviews and supported community members in integrating
changes into FreeBSD, and triaged incoming bug reports.
</p>
<p>We contributed enhancements to many kernel and userland subsystems, including
the x86 pmap layer, ELF run-time linker and kernel loader, the Capsicum
sandboxing framework and Casper services, the threading library, some RISC-V
changes, the build system, tool chain and freebsd-update, network stack
stability improvements, machine-dependent optimizations, new kernel interfaces,
DTrace bug fixes, documentation improvements, and others.
</p>
<h3>Continuous Integration and Quality Assurance</h3>

<p>The Foundation provides a full-time staff member and funds projects on
improving continuous integration, automated testing, and overall quality
assurance efforts for the FreeBSD Project.
</p>
<p>During the fourth quarter of 2020, Foundation staff continued improving and
monitoring the Project's CI infrastructure, and working with experts to fix
the failing builds and the regressions found by tests.  The work was focused
on pre-commit tests and development of the CI staging environment.  The other
main working item is working on the VCS migration to change the src and doc
source from Subversion to Git.  There are also many work-in-progress tasks like
analysis and improve the tests of non-x86 platforms.
</p>
<p>See the FreeBSD CI section of this report for completed work items and detailed
information.
</p>
<h3>Supporting FreeBSD Infrastructure</h3>

<p>The Foundation provides hardware and support to improve the FreeBSD
infrastructure.  Last quarter, we continued supporting FreeBSD hardware located
around the world.  We coordinated efforts between the new NYI Chicago facility
and clusteradm to start working on getting the facility prepared for some of
the new FreeBSD hardware we are planning on purchasing.  NYI generously
provides this for free to the Project.  We also worked on connecting with the
new owners of the NYI Bridgewater site, where most of the existing FreeBSD
infrastructure is located.
</p>
<p>Some of the purchases we made for the Project last quarter to support
infrastructure includes:
</p>
<ul>
<li><p>5 application servers to run tasks like bugzilla, wiki, website, cgi,
    Phabricator, host git, etc.
</p></li>
<li><p>1 server to replace the old pkg server, which will provide a lot more IOPS
    to avoid the slowdowns seen during peak times of the day where the disks
    simply cannot keep up with the request volume.
</p></li>
<li><p>1 server for exp-runs and to make them faster.
</p></li>
<li><p>1 server to build packages more frequently.
</p>
</li></ul>
<h3>FreeBSD Advocacy and Education</h3>

<p>A large part of our efforts are dedicated to advocating for the Project.  This
includes promoting work being done by others with FreeBSD; producing advocacy
literature to teach people about FreeBSD and help make the path to starting
using FreeBSD or contributing to the Project easier; and attending and getting
other FreeBSD contributors to volunteer to run FreeBSD events, staff FreeBSD
tables, and give FreeBSD presentations.
</p>
<p>The FreeBSD Foundation sponsors many conferences, events, and summits around
the globe. These events can be BSD-related, open source, or technology events
geared towards underrepresented groups. We support the FreeBSD-focused events
to help provide a venue for sharing knowledge, to work together on projects,
and to facilitate collaboration between developers and commercial users.  This
all helps provide a healthy ecosystem. We support the non-FreeBSD events to
promote and raise awareness of FreeBSD, to increase the use of FreeBSD in
different applications, and to recruit more contributors to the Project.
</p>
<p>While we were still unable to attend in-person meetings due to COVID-19, we
were able to attend virtual events at new venues and facilitate the first
online FreeBSD Vendor Summit.  In addition to attending and planning virtual
events, we are continually working on new training initiatives and updating our
selection of <a href='https://freebsdfoundation.org/freebsd-project/resources/'>how-to guides</a> to facilitate getting more folks to try out FreeBSD.
</p>
<p>Check out some of the advocacy and education work we did last quarter:
</p>
<ul>
<li><p>Continued our FreeBSD Fridays series of 101 classes. Topics included an
    Introduction to Capsicum, Introduction to Bhyve, Introduction to DTrace, and
    more.  Videos of the past sessions can be found <a href='https://freebsdfoundation.org/freebsd-fridays/'>here</a>. We'll be back with new
    sessions in early 2021.
</p></li>
<li><p>Gave a FreeBSD talk at the nerdear.la conference on October 20th.
</p></li>
<li><p>Participated in the podcast: <a href='https://freebsdfoundation.org/news-and-events/latest-news/what-the-dev-podcast-a-dive-into-the-freebsd-foundation-on-its-20th-anniversary/'>What the Dev: A Dive into the FreeBSD Foundation on its 20th Anniversary</a>
</p></li>
<li><p>Promoted the Foundation's 20th Anniversary in the FossBytes article:
    <a href='https://freebsdfoundation.org/news-and-events/latest-news/fossbytes-20-years-of-the-freebsd-foundation/'>20 Years of The FreeBSD Foundation</a>
</p></li>
<li><p>Continued to promote the FreeBSD Office Hours series.  Videos from the one hour
    sessions can be found on the Project's <a href='https://www.youtube.com/channel/UCxLxR_oW-NAmChIcSkAyZGQ'>YouTube Channel</a>.  See the Office Hours
    section of this report for more information.
</p></li>
<li><p>Added two new How-To Guides: <a href='https://freebsdfoundation.org/contributing-freebsd-documentation/'>Contributing FreeBSD Documentation</a>
    and <a href='https://freebsdfoundation.org/freebsd-project/resources/how-to-submit-a-bug-report/'>How to Submit a Bug Report</a>.
</p></li>
<li><p>Worked with the organizing committee to host the <a href='https://wiki.freebsd.org/DevSummit/202011'>November 2020 Vendor Summit</a>
</p></li>
<li><p>Promoted the <a href='https://freebsdfoundation.org/news-and-events/latest-news/freebsd-essential-to-bringing-cheri-and-arms-morello-processor-to-life/'>use of FreeBSD</a> in regards to CHERI and ARM's Morello Processor
</p></li>
<li><p>Authored a <a href='https://www.fosslife.org/beginners-guide-freebsd'>Beginners Guide to FreeBSD</a> for Fosslife.
</p></li>
<li><p>Sponsored All Things Open as a Media Sponsor.
</p></li>
<li><p>Sponsored OpenZFS Developers Summit at the Bronze level.
</p></li>
<li><p>Applied for a virtual stand at FOSDEM 2021.
</p></li>
<li><p>Committed to attend the online Apricot 2021.
</p>
</li></ul>
<p>Keep up to date with our latest work in our newsletters:
<a href='https://www.freebsdfoundation.org/news-and-events/newsletter/'>https://www.freebsdfoundation.org/news-and-events/newsletter/</a>
</p>
<p>Netflix provided an update on how and why they use FreeBSD in our latest
<a href='https://freebsdfoundation.org/blog/freebsd-case-study-netflix/'>Contributor Case Study</a>.
</p>
<p>We help educate the world about FreeBSD by publishing the professionally
produced FreeBSD Journal.  As we mentioned previously, the FreeBSD Journal is
now a free publication.  Find out more and access the latest issues at
<a href='https://www.FreeBSDfoundation.org/journal/'>https://www.FreeBSDfoundation.org/journal/</a>
</p>
<p>You can find out more about events we attended and upcoming events at
<a href='https://www.FreeBSDfoundation.org/news-and-events/'>https://www.FreeBSDfoundation.org/news-and-events/</a>.
</p>
<h3>Legal/FreeBSD IP</h3>

<p>The Foundation owns the FreeBSD trademarks, and it is our responsibility to
protect them.  We also provide legal support for the core team to investigate
questions that arise.
</p>
<p>Go to <a href='http://www.FreeBSDfoundation.org'>http://www.FreeBSDfoundation.org</a> to find out how we support FreeBSD and
how we can help you!
</p></body></project>
<project cat='team'>
<title>FreeBSD Release Engineering Team
</title>

<contact>
<person>
<name>FreeBSD Release Engineering Team</name>
<email>re@FreeBSD.org</email>
</person>
</contact>

<links>
<url href='https://www.freebsd.org/releases/12.2R/schedule.html'>FreeBSD 12.2-RELEASE schedule</url>
<url href='https://www.freebsd.org/releases/13.0R/schedule.html'>FreeBSD 13.0-RELEASE schedule</url>
<url href='https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/'>FreeBSD development snapshots</url>
</links>

<body><p>The FreeBSD Release Engineering Team is responsible for setting
and publishing release schedules for official project releases
of FreeBSD, announcing code freezes and maintaining the respective
branches, among other things.
</p>
<p>During the fourth quarter of 2020, the Release Engineering Team completed
work on 12.2-RELEASE, the third release from the stable/12 branch, released
on October 27.  Thank you to all involved for the hard work that went into
this release.
</p>
<p>Additionally throughout the quarter, several development snapshots builds
were released for the head, stable/12, and stable/11 branches.
Development snapshot builds for 13.0-CURRENT have recently been built from
the Git tree within the project, while further snapshot builds for 12.x and
11.x will continue to be built from Subversion.  As we approach the end of
2020, continued preparations are being put in place for the upcoming 13.0
release, which will be the first release from Git.
</p>
<p>Much of this work was sponsored by Rubicon Communications, LLC (netgate.com)
and the FreeBSD Foundation.
</p></body></project>
<project cat='team'>
<title>Cluster Administration Team</title>

<contact>
<person>
<name>Cluster Administration Team</name>
<email>clusteradm@FreeBSD.org</email>
</person>
</contact>

<links>
<url href='https://www.freebsd.org/administration.html#t-clusteradm'>Cluster Administration Team members</url>
</links>

<body><p>The FreeBSD Cluster Administration Team consists of the people responsible for
administering the machines that the Project relies on for its distributed work
and communications to be synchronised. In this quarter, the team has worked
on the following:
</p>
<ul>
<li><p>Finished setting up the Malaysia mirror site, generously hosted by the
    <a href='https://myren.net.my/'>Malaysian Research &amp; Education Network</a>.  Traffic
    from Oceania and parts of Asia is now going to this mirror instead of
    farther away sites like Japan and California.
</p></li>
<li><p>Upgraded the package building machines to a version of head from
    mid-October 2020.
</p></li>
<li><p>Upgraded developer machines in the cluster (freefall, ref* and universe*) to
    a version of head from mid-October 2020.
</p></li>
<li><p>Installed eight new x86 servers in our New Jersey site:
    five application servers, two package builders and one mirror server.
</p><ul>
<li><p>The new mirror server is in production (pkg0.nyi.freebsd.org).
</p></li>
<li><p>The two package builders are in production.
</p></li>
<li><p>Two of the application servers have been put into production as the Git
source of truth and the cgit web frontend, respectively.
</p></li></ul>
</li><li><p>Installed two new aarch64 servers in our New Jersey site.  Both are now
    building aarch64 packages.
</p></li>
<li><p>Fixed package mirror synchronisation for powerpc64 packages.
</p></li>
<li><p>Rebuilt the ZFS pool on the UK mirror server (pkg0.bme.freebsd.org) for
    better I/O parallelism.  This should improve download performance
    especially at peak times.
</p></li>
<li><p>Ongoing systems administration work:
</p><ul>
<li><p>Accounts management for committers.
</p></li>
<li><p>Backups of critical infrastructure.
</p></li>
<li><p>Keeping up with security updates in 3rd party software.
</p>
</li></ul>
</li></ul>
Work in progress:

<ul>
<li><p>Hardware refreshing for web services, backup version control system in NYI
</p></li>
<li><p>Upgrading production machines in the FreeBSD cluster to 12.2
</p><ul>
<li><p>Most machines have been upgraded as of mid-December 2020
</p></li>
<li><p>Remaining machines will be decommissioned / repurposed after services
migrate to newer hardware
</p></li></ul>
</li><li><p>Supporting Git migration and infrastructure setup
</p></li>
<li><p>powerpc pkgbuilder/ref/universal machines
</p></li>
<li><p>Preparations for a new mirror site in Australia, to be hosted by
    <a href='https://www.ix.asn.au'>IX Australia</a>.
</p></li>
<li><p>Setup Brazil (BRA) mirror.
</p></li>
<li><p>Review the service jails and service administrators operation.
</p></li>
<li><p>Searching for more providers that can fit the requirements for a
    <a href='https://wiki.freebsd.org/Teams/clusteradm/generic-mirror-layout'>generic mirrored layout</a>
    or a
    <a href='https://wiki.freebsd.org/Teams/clusteradm/tiny-mirror'>tiny mirror</a>.
</p></li></ul>
</body></project>
<project cat='team'>
<title>Continuous Integration</title>

<links>
<url href='https://ci.FreeBSD.org'>FreeBSD Jenkins Instance</url>
<url href='https://ci.FreeBSD.org/hwlab'>FreeBSD Hardware Testing Lab</url>
<url href='https://artifact.ci.FreeBSD.org'>FreeBSD CI artifact archive</url>
<url href='https://hackmd.io/@FreeBSD-CI'>FreeBSD CI weekly report</url>
<url href='https://wiki.freebsd.org/Jenkins'>FreeBSD Jenkins wiki</url>
<url href='https://wiki.freebsd.org/HostedCI'>Hosted CI wiki</url>
<url href='https://wiki.freebsd.org/3rdPartySoftwareCI'>3rd Party Software CI</url>
<url href='https://preview.tinyurl.com/y9maauwg'>Tickets related to freebsd-testing@</url>
<url href='https://github.com/freebsd/freebsd-ci'>FreeBSD CI Repository</url>
</links>

<contact>
<person>
<name>Jenkins Admin</name>
<email>jenkins-admin@FreeBSD.org</email>
</person>
<person>
<name>Li-Wen Hsu</name>
<email>lwhsu@FreeBSD.org</email>
</person>
</contact>
<body><p>Contact: <a href='https://lists.FreeBSD.org/mailman/listinfo/freebsd-testing'>freebsd-testing Mailing List</a><br />
Contact: IRC #freebsd-ci channel on EFNet<br />
</p>
<p>The FreeBSD CI team maintains the continuous integration system
of the FreeBSD project.  The CI system firstly checks the committed changes
can be successfully built, then performs various tests and analysis over the
newly built results.
The artifacts from those builds are archived in the artifact server for
further testing and debugging needs.  The CI team members examine the
failing builds and unstable tests and work with the experts in that area to
fix the code or adjust test infrastructure.  The details of these efforts
are available in the <a href='https://hackmd.io/@FreeBSD-CI'>weekly CI reports</a>.
</p>
<p>During the fourth quarter of 2020, we continued working with the contributors and
developers in the project to fulfil their testing needs and also keep
collaborating with external projects and companies to improve their products
and FreeBSD.
</p>
<p>Important changes:
</p>
<ul>
<li><p>doc jobs were changed to use git to follow VCS migration:
</p><ul>
<li><p><a href='https://ci.freebsd.org/job/FreeBSD-doc-main/'>https://ci.freebsd.org/job/FreeBSD-doc-main/</a>
</p></li>
<li><p><a href='https://ci.freebsd.org/job/FreeBSD-doc-main-igor/'>https://ci.freebsd.org/job/FreeBSD-doc-main-igor/</a>
    Thanks Brandon Bergren (bdragon@)
</p></li></ul>
</li><li><p>head and stable/12 build environment have been upgraded to 12.2-RELEASE
</p>
</li></ul>
New jobs added:

<ul>
<li><p><a href='https://ci.freebsd.org/job/FreeBSD-head-riscv64-LINT'>LINT kernel of head on riscv64</a>
</p>
</li></ul>
Work in progress:

<ul>
<li><p>Follow VCS migration, change src jobs to use Git - PRs are
    <a href='https://github.com/freebsd/freebsd-ci/pull/121'>available</a>
    Thanks Brandon Bergren (bdragon@)
</p></li>
<li><p>Collecting and sorting CI tasks and ideas
    <a href='https://hackmd.io/@FreeBSD-CI/freebsd-ci-todo'>here</a>
</p></li>
<li><p>Testing and merging pull requests in the
    <a href='https://github.com/freebsd/freebsd-ci/pulls'>the FreeBSD-ci repo</a>
</p></li>
<li><p>Designing and implementing pre-commit CI building and testing
</p></li>
<li><p>Reducing the procedures of CI/test environment setting up for contributors and
    developers
</p></li>
<li><p>Setting up the CI stage environment and putting the experimental jobs on it
</p></li>
<li><p>Setting up public network access for the VM guest running tests
</p></li>
<li><p>Implementing automatic tests on bare metal hardware
</p></li>
<li><p>Adding drm ports building tests against -CURRENT
</p></li>
<li><p>Planning to run ztest and network stack tests
</p></li>
<li><p>Adding more external toolchain related jobs
</p></li>
<li><p>Improving the hardware lab to be more mature and adding more hardware
</p></li>
<li><p>Helping more software get FreeBSD support in their CI pipeline
    Wiki pages: <a href='https://wiki.freebsd.org/3rdPartySoftwareCI'>3rdPartySoftwareCI</a>,
    <a href='https://wiki.freebsd.org/HostedCI'>HostedCI</a>
</p></li>
<li><p>Working with hosted CI providers to have better FreeBSD support
</p></li>
<li><p>The build and test results will be sent to the
    <a href='https://lists.freebsd.org/mailman/listinfo/dev-ci'>dev-ci mailing list</a>
    soon. Feedback and help with analysis is very appreciated!
</p>
</li></ul>
Please see freebsd-testing@ related tickets for more WIP information, and don't hesitate to join the effort!

<p>Sponsor: The FreeBSD Foundation
</p></body></project>
<project cat='team'>
<title>Ports Collection</title>

<links>
<url href='https://www.FreeBSD.org/ports/'>About FreeBSD Ports</url>
<url href='https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/ports-contributing.html'>Contributing to Ports</url>
<url href='http://portsmon.freebsd.org/index.html'>FreeBSD Ports Monitoring</url>
<url href='https://www.freebsd.org/portmgr/index.html'>Ports Management Team</url>
<url href='http://ftp.freebsd.org/pub/FreeBSD/ports/ports/'>Ports Tarball</url>
</links>

<contact>
<person>
<name>René Ladan</name>
<email>portmgr-secretary@FreeBSD.org</email>
</person>
<person>
<name>FreeBSD Ports Management Team</name>
<email>portmgr@FreeBSD.org</email>
</person>
</contact>

<body><p>The Ports Management Team is responsible for overseeing the
overall direction of the Ports Tree, building packages, and
personnel matters.  Below is what happened in the last quarter.
</p>
<p>For the last quarter the dashboard looks like:
</p>
<ul>
<li><p>41500 ports (including flavors)
</p></li>
<li><p>2516 open PRs of which 625 are unassigned
</p></li>
<li><p>8715 commits to the HEAD branch by 164 committers
</p></li>
<li><p>420 commits to the 2020Q4 branch by 59 committers
</p>
</li></ul>
Compared to the third quarter, the PR statistics mostly stayed the same. There
<p>were slightly fewer commits by the same number of people. The number of ports
again grew steadily, this time by almost 4 percent.
</p>
<p>During the last quarter, we welcomed Juray Lutter (otis@) as a new ports
committer and said goodbye to cpm, jadawin, knu, araujo, mmokhi and scottl.
</p>
<p>Traditionally merges to the quarterly ports branches, which are more
conservative versions of the HEAD tree, required approval of either the
Ports Security Team (ports-secteam@) or portgmr@. There were already a number
of blanket approvals for tested commits, ranging from fixing typing mistakes to
upgrading web browsers to their latest version. As of last December, all
ports committers are free to merge on their own, lessening the burden on
ports-secteam@.
</p>
<p>Patent limitations have been disconnected from the license framework, given
that patents are a complex topic with implications varying from one jurisdiction
to another.
</p>
<p>The last quarter saw a number of updates to default versions of ports:
</p>
<ul>
<li><p>librsvg2: "rust" on supported platforms, "legacy"
    otherwise
</p></li>
<li><p>Mono: 5.10
</p></li>
<li><p>FPC switched to 3.2.0
</p></li>
<li><p>GCC switched to 10 for powerpc64le
</p></li>
<li><p>Lazarus switched to 2.0.10
</p></li>
<li><p>Ruby switched to 2.7.X
</p></li>
<li><p>Samba switched to 4.12
</p>
</li></ul>
During the last quarter, a new virtual category was added: "education" for ports
<p>that for instance help the user to learn about a certain topic or help
facilitating examinations.
</p>
<p>The @shell and @sample keywords have been rewritten in Lua which makes root-dir
compliant (see pkg -r) and ensures they are Capsicum-sandboxed.
</p>
<p>The last quarter also saw updates to several user-facing ports:
</p>
<ul>
<li><p>Firefox 84.0.1
</p></li>
<li><p>Firefox-esr 78.6.0
</p></li>
<li><p>Chromium 87.0.4280.88
</p></li>
<li><p>Ruby 2.7.2
</p></li>
<li><p>Qt5 5.15.2
</p></li>
<li><p>XFce 4.16
</p>
</li></ul>
As always, antoine@ was busy running exp-runs, 37 this quarter, testing:

<ul>
<li><p>various ports upgrades
</p></li>
<li><p>changing sys/cdefs.h in base
</p></li>
<li><p>adding "set pipefail" to most framework scripts to catch errors earlier
</p></li>
<li><p>changing the default locale to C.UTF-8 in base
</p></li>
<li><p>using bsdgrep as /usr/bin/grep
</p></li></ul>
</body></project>
<project cat='team'>
<title>Office Hours</title>

<contact>
<person>
<name>Allan Jude</name>
<email>allanjude@freebsd.org</email>
</person>
<person>
<name>Ed Maste</name>
<email>emaste@freebsd.org</email>
</person>
</contact>

<body><p>During the final quarter of 2020 three office hours sessions were held.
</p>
<p>The first was hosted by the core team in a time slot conducive to Asia and
Australia, covering topics including the transition to git, recruiting for
project teams, and core's todo list.
</p>
<p>The second was hosted by the git transition team, and answered attendee
questions about the transition to git and how it would impact the project's
workflows.
</p>
<p>The third session was hosted by bhyve maintainers Peter Grehan and John Baldwin
to present recent development efforts and answer questions about bhyve.
</p>
<p>The project is looking for volunteers to host future office hours sessions, as
well as taking topic suggestions. We also hope to improve the system to allow people
to submit questions ahead of time, so that we can take maximum advantage of
subject matter experts when we have them for these calls.
</p>
<p>You can find the schedule for future office hours, and videos of past
office hours on the <a href='https://wiki.freebsd.org/OfficeHours'>FreeBSD Wiki</a>
</p>
<p>Sponsor: ScaleEngine Inc.
</p></body></project>
<project cat='proj'>
<title>GPL in Base</title>

<links>
<url href='https://wiki.freebsd.org/GPLinBase'>GPL Software in the Base System</url>
</links>

<contact>
<person>
<name>Ed Maste</name>
<email>emaste@FreeBSD.org</email>
</person>
<person>
<name>Kyle Evans</name>
<email>kevans@FreeBSD.org</email>
</person>
<person>
<name>Baptiste Daroussin</name>
<email>bapt@FreeBSD.org</email>
</person>
</contact>

<body><p>A long-standing goal of the FreeBSD project is for the base system to migrate
to modern, copyfree or more permissively licensed components.  In this quarter,
the following components have been successfully removed or replaced:
</p>
<ul>
<li><p>gdb (<a href='https://cgit.freebsd.org/src/commit/?id=1c0ea326aa6d'>removed</a> in favor of lldb in base or devel/gdb in ports)
</p></li>
<li><p>gnugrep (<a href='https://cgit.freebsd.org/src/commit/?id=b82a9ec5f53e'>replaced</a> with bsdgrep)
</p></li>
<li><p>libgnuregex (<a href='https://cgit.freebsd.org/src/commit/?id=8aff76fb37b5'>removed</a>)
</p>
</li></ul>
The following component(s) have yet to be claimed.  Some replacement prospects
<p>may be listed on the above-linked wiki page. Interested parties are welcome to
evaluate the options to restart the discussion:
</p>
<ul>
<li><p>dialog
</p></li>
<li><p>gcov (kernel)
</p>
</li></ul>
The following component(s) have a principal investigator to coordinate work.
<p>Note that partial completion likely means that a component is partially
compatible, but could use evaluation and patches to bring parity with the
component that it is replacing.
</p>
<ul>
<li><p>diff3 (Contact bapt@ if interested)
</p></li></ul>
</body></project>
<project cat='proj'>
<title>Git Migration Working Group</title>

<links>
<url href='https://cgit.FreeBSD.org/src'>src (base system) git repo</url>
<url href='https://cgit.FreeBSD.org/doc'>doc git repo</url>
<url href='https://cgit-dev.FreeBSD.org/ports'>Beta ports git repo</url>
<url href='https://github.com/bsdimp/freebsd-git-docs'>Warner's git documentation repo</url>
<url href='https://lists.freebsd.org/mailman/listinfo/freebsd-git'>FreeBSD-git mailing list</url>
<url href='https://github.com/freebsd/git_conv'>Git conversion tooling repo</url>
<url href='http://gameoftrees.org/'>Game of Trees</url>
<url href='https://github.com/johnmehr/gitup'>gitup</url>
</links>

<contact>
<person>
<name>Li-Wen Hsu</name>
<email>lwhsu@FreeBSD.org</email>
</person>
<person>
<name>Warner Losh</name>
<email>imp@FreeBSD.org</email>
</person>
<person>
<name>Ed Maste</name>
<email>emaste@FreeBSD.org</email>
</person>
<person>
<name>Ulrich Spörlein</name>
<email>uqs@FreeBSD.org</email>
</person>
</contact>

<body><p>The Git working group largely completed the migration of the doc and src
(base system) trees from Subversion to Git in December 2020.  We are currently
working on some minor outstanding issues and preparing for the ports tree
migration.
</p>
<p>We set up new hosts to serve as the Git repositories and mirrors, and developed
commit hooks for restrictions on commits to various branches, generation of
commit mail, and similar needs.
</p>
<p>The doc tree migration occurred on December 8th and 9th.  After the conversion
some minor changes to the documentation build infrastructure were necessary.
</p>
<p>The src tree migration occurred between December 20th and 23rd for the main
branch; some additional tasks occurred over the next week or so.  These
included enabling the stable branches, vendor (contrib) code updates, and
the git->svn gateway.  We are translating stable branch commits to Subversion
for the stable/11 and stable/12 branches and associated release branches.  This
allows FreeBSD users who follow stable branches or releases to continue using
existing processes and tooling.
</p>
<p>An experimental Git conversion of the ports tree is available at the link
above.  There are some unique challenges in the ports tree (that do not impact
the doc or src repos in the same way), so additional work is ongoing.  The
window for migrating the ports tree is immediately prior to a quarterly
branch, so we anticipate a migration at the end of March 2021.  Over the next
few months testing of the experimental ports repo is very welcome.
</p>
<p>Process documentation for developer and user interaction with FreeBSD's
repositories is currently available in Warner's GitHub repository at the link
above.  It will be moved to the FreeBSD developer's handbook and/or other
suitable locations following the documentation project's asciidoc conversion.
</p>
<p>The working group is experimenting with two permissively-licensed tools that
are compatible with Git servers or repositories.  Game of Trees is a version
control system that is compatible with Git repositories.  It is being developed
by Stefan Sperling along with some OpenBSD developers and other contributions.
</p>
<p>John Mehr's gitup is a minimal, dependency-free program that clones and
synchronizes a local tree with a remote repository.  It is intended for use
cases that would otherwise be served by tools like portsnap.
</p>
<p>Sponsor: The FreeBSD Foundation (in part)
</p></body></project>
<project cat='proj'>
<title>Linux compatibility layer update</title>

<contact>
<person>
<name>Edward Tomasz Napierala</name>
<email>trasz@FreeBSD.org</email>
</person>
</contact>

<body><p>Linuxulator improvements have been ongoing for the last two years,
with support from the FreeBSD foundation over a few distinct project
grants as well as contributions from the community.
The goal of this project is to improve FreeBSD's ability to execute
unmodified Linux binaries.
Current status is being tracked at <a href='https://wiki.freebsd.org/LinuxApps'>Linux app status Wiki page</a>.
The work has now shifted from command-line apps to desktop applications.
</p>
<p>There wasn't much Foundation-sponsored work done during this quarter,
apart from extending fuse(4) to make it possible to run Linux FUSE
servers, which is one of the things required to run AppImages.
The Foundation-sponsored effort will continue into the first quarter
of 2021 in order to make sure the 13.0-RELEASE ships with Linuxulator in a good shape.
</p>
<p>There was a very significant contribution from Conrad Meyer in the form
of <code>SO_PASSCRED</code> setsockopt(2) support, <code>PR_SETDUMPABLE</code> and <code>PR_GETDUMPABLE</code>
prctl(2) flags, and also <code>CLONE_FS</code> and <code>CLONE_FILES</code> handling.  This,
along with some more cleanups and improvements, leads to working Linux
Chromium; it has been tested with Netflix and Spotify clients.  It still
requires three flags (<code>--no-sandbox --no-zygote --in-process-gpu</code>)
to be passed on the command line to work around missing functionality, though.  Also,
the name_to_handle_at(2) and open_by_handle_at(2) syscalls are now supported.
There are also much better debug messages for unrecognized socket options.
</p>
<p>Sponsor: The FreeBSD Foundation
</p></body></project>
<project cat='proj'>
<title>LLDB Debugger Improvements</title>

<links>
<url href='https://www.moritz.systems/blog/lldb-debugger-improvements-for-freebsd/'>Moritz Systems Project Description</url>
<url href='https://freebsdfoundation.org/blog/guest-blog-foundation-sponsors-freebsd-lldb-improvements/'>FreeBSD Foundation Blog</url>
<url href='https://github.com/moritz-systems/llvm-project'>Git Repository</url>
</links>

<contact>
<person>
<name>Kamil Rytarowski</name>
<email>kamil@moritz.systems</email>
</person>
<person>
<name>Michał Górny</name>
<email>mgorny@moritz.systems</email>
</person>
</contact>

<body><p>The LLDB project builds on libraries provided by LLVM and Clang to provide a
great modern debugger. It uses the Clang ASTs and the expression parser, LLVM
JIT, LLVM disassembler, etc so that it provides an experience that “just
works”. It is also blazing fast and more permissively licensed than GDB, the
GNU Debugger.
</p>
<p>LLDB is the default debugger in Xcode on macOS and supports debugging C,
Objective-C, and C++ on the desktop and iOS devices and the simulator.
</p>
<p>FreeBSD includes LLDB in the base system. At present, it has some limitations
in comparison with the GNU GDB debugger, and does not yet provide a complete
replacement. It used to rely on an obsolete plugin model in LLDB that was a
growing technical debt. This project aimed to bring LLDB closer to a fully
featured replacement for GDB, and therefore for FreeBSD to feature a modern
debugger for software developers.
</p>
<p>The legacy monolithic target support executed the application being debugged in
the same process space as the debugger. The modern LLDB plugin approach, used
on other supported targets, executes the target process under a separate
lldb-server process. This improves reliability and simplifies the process /
thread model in LLDB itself. In addition, remote and local debugging is now
performed using the same approach.
</p>
<p>After the migration to the new process model on 32 and 64-bit x86 CPUs, the
project focused on reviewing the results of LLDB’s test suite and fixing tests
as time permits.
</p>
<p>During the Moritz Systems work, the FreeBSD Project gained numerous important
improvements: in the kernel, userland base libraries (the dynamic loader) and
the LLVM toolchain FreeBSD support.
</p>
<p>The introduced changes are expected to be shipped with LLDB 12.0, and where
applicable in FreeBSD 13.0.
</p>
<p>The overall experience of FreeBSD/LLDB developers and advanced users on this
rock solid Operating System reached the state known from other environments.
Furthermore, the FreeBSD-focused work also resulted in generic improvements,
enhancing the LLDB support for Linux and NetBSD.
</p>

<p>Sponsor: The FreeBSD Foundation<br />
</p></body></project>
<project cat='proj'>
<title>Upstreaming NetApp Changes</title>

<links>
<url href='https://klarasystems.com/freebsd-development/'>Klara Inc.</url>
</links>

<contact>
<person>
<name>Alexander Sideropoulos</name>
<email>Alexander.Sideropoulos@netapp.com</email>
</person>
<person>
<name>Allan Jude</name>
<email>allan@klarasystems.com</email>
</person>
</contact>

<body><p>NetApp has started an effort to upstream bug fixes and other improvements from
the ONTAP code line into FreeBSD. These changes benefit the FreeBSD
community by providing many fixes that NetApp has made over the past few years,
while allowing NetApp to reduce the number of customizations needed when
bringing in the latest FreeBSD changes back into the ONTAP tree.
</p>
<p>NetApp has partnered with Klara to facilitate this project, to help identify
interesting and useful changes to send upstream, to rework and generalize those
changes as required to make them suitable for upstreaming, and to shepherd them
through the FreeBSD code review process.
</p>
<p>During the fourth quarter, Klara has made 40 upstream fixes in the FreeBSD
kernel in various subsystems including geom, dev, amd64, net, kern, netinet, and
several other areas of the tree on behalf of NetApp.
</p>
<p>NetApp intends to continue to sponsor this effort throughout 2021.
</p>
<p>Sponsor: NetApp
</p></body></project>
<project cat='proj'>
<title>NFS over TLS implementation</title>

<contact>
<person>
<name>Rick Macklem</name>
<email>rmacklem@freebsd.org</email>
</person>
</contact>

<body><p>In an effort to improve NFS security, an Internet Draft titled
"Towards Remote Procedure Call Encryption By Default" specifies
use of TLS 1.3 to encrypt all data traffic on a Sun RPC
connection used for NFS.
</p>
<p>Although NFS has been able to use sec=krb5p to encrypt data
on the wire, this requires a Kerberos environment and, as
such, has not been widely adopted.
It also required that
encryption/decryption be done in software, since only the
RPC message NFS arguments are encrypted.
Since Kernel TLS is capable of using hardware assist to
improve performance and does not require Kerberos, NFS
over TLS may be more widely adopted, once implementations
are available.
</p>
<p>The coding for this project has now been completed.
All required changes to the NFS and kernel RPC code have
been committed to the head/current kernel and will be in FreeBSD13.
The daemons can now be built from a port that depends
upon the security/openssl-devel port of Openssl3 that
includes patches for support of ktls.
The port for the daemons is called sysutils/nfs-over-tls
and should be committed to the ports framework soon.
In the meantime, the port can easily be fetched,
as described in
<a href='https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt'>https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt</a>.
</p>
<p>To support clients such as laptops, the daemons that perform the TLS
handshake may optionally handle client X.509 certificates from a
site local CA.
There are now exports(5) options to require client(s) to
provide a valid X.509 certificate.
The case where a "user" name is stored in the certificate and is used
to map all RPC credentials to that user is probably in violation of
the Internet Draft.
This is only enabled when the "-u" command line
option is provided to rpc.tlsservd(8).
</p>
<p>The code is now available for testing. See:
<a href="https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt">https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt</a>
</p>
<p>
Setting up system(s) for testing still requires building a custom kernel
with "options KERN_TLS" from recent head/FreeBSD13 sources plus installing
the port for the daemons, as explained by the above document.
</p>
<p>The main limitation in the current implementation is that it uses TLS1.2
and not TLS1.3, as required by the Internet Draft.
This should change once the KERN_TLS rx patch includes TLS1.3 support.
</p>
<p>Third party testing would be appreciated.
</p></body></project>
<project cat='proj'>
<title>OpenBSM Synchronisation</title>

<links>
<url href='http://www.trustedbsd.org/openbsm.html'>TrustedBSD / OpenBSM</url>
<url href='https://github.com/openbsm/openbsm'>OpenBSM Github Sources</url>
<url href='https://github.com/openbsm/openbsm/commit/54a0c07cf8bac71554130e8f6760ca68e5f36c7f'>Synchronisation with macOS Catalina</url>
<url href='https://opensource.apple.com'>Apple OpenSource</url>
</links>

<contact>
<person>
<name>Gordon Bergling</name>
<email>gbe@FreeBSD.org</email>
</person>
</contact>

<body><p>OpenBSM is a crucial part of FreeBSD, which provides auditing features for
the operating system. OpenBSM is incorporated into FreeBSD and macOS.
Both Apple and FreeBSD have currently made changes to the OpenBSM framework,
which weren't upstreamed. This small project aims to consolidate
these changes and upstream them to the OpenBSM github repository, so that
both development efforts can be merged to FreeBSD later on. The tricky part
of this project is the manual comparison, since Apple doesn't provide any
changelogs.
</p>
<p>I am currently working on on the macOS Catalina sources and hopefully Apple 
will release the sources of macOS Big Sur in time for FreeBSD 13.
</p></body></project>
<project cat='proj'>
<title>Tool Chain</title>

<contact>
<person>
<name>Dimitry Andric</name>
<email>dim@FreeBSD.org</email>
</person>
<person>
<name>Ed Maste</name>
<email>emaste@FreeBSD.org</email>
</person>
</contact>

<links>
<url href='https://sourceforge.net/p/elftoolchain'>ELF Tool Chain homepage</url>
</links>

<body><p>In October Clang/LLVM was updated to 11.0.0, followed by a number of bug fixes
from upstream, including improvements for a number of Tier-2 architectures.
We also enabled the <code>-fstack-clash-protection</code> flag to enable compiler
mitigation for the "stack clash" vulnerability and are coordinating with
upstream.
</p>
<p>Upstream LLDB support for FreeBSD improved substantially over the last quarter,
as detailed elsewhere in this report.  These improvements will make it into the
FreeBSD base system early in 2021 when LLVM is next updated to 12.0.  As also
mentioned elsewhere, we removed the obsolete copy of GDB 6.1.1.
</p>
<p>The ELF Tool Chain received a number of bug fixes, as well as support for
<code>readelf -z</code> (handling compressed ELF debug sections) and an improvement
to addr2line to report based on labels when other debug information is not
available.  We are working to upstream these changes to the ELF Tool Chain
project.
</p>
<p>There are a number of open issues and opportunities for improvements in various
ELF Tool Chain components.  Contributions in these areas are very welcome,
</p>
<p>Sponsor: The FreeBSD Foundation (in part)
</p></body></project>
<project cat='kern'>
<title>ENA FreeBSD Driver Update</title>

<links>
<url href='https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ena/README'>ENA README</url>
</links>

<contact>
<person>
<name>Michal Krawczyk</name>
<email>mk@semihalf.com</email>
</person>
<person>
<name>Artur Rojek</name>
<email>ar@semihalf.com</email>
</person>
<person>
<name>Marcin Wojtas</name>
<email>mw@semihalf.com</email>
</person>
</contact>

<body><p>ENA (Elastic Network Adapter) is the smart NIC available in the
virtualized environment of Amazon Web Services (AWS). The ENA
driver supports multiple transmit and receive queues and can handle
up to 100 Gb/s of network traffic, depending on the instance type
on which it is used.
</p>
<p>Completed since the last update:
</p>
<ul>
<li><p>MFC of the ENA v2.3.0 driver to the FreeBSD 11-STABLE branch
</p></li>
<li><p>MFC of the ENA v2.3.0 driver to the upcoming FreeBSD 12-STABLE branch
</p></li>
<li><p>Add feature that allows reading extra ENI (Elastic Network Interface)
    metrics about exceeding BW/pps limits
</p></li>
<li><p>Add SPDX license tag to the ENA driver files
</p></li>
<li><p>Add Rx offsets (hardware feature) support for the ENA driver
</p></li>
<li><p>Fix completion descriptors alignment for the ENA device - on some of
    the platforms ENA needs alignment to 4k
</p>
</li></ul>
Work in progress:

<ul>
<li><p>Introduce full kernel RSS API support.
</p></li>
<li><p>Allow reconfiguration of the RSS indirection table and hash key
</p></li>
<li><p>Prototype the driver port to the iflib framework
</p>
</li></ul>
Sponsor: Amazon.com Inc
</body></project>
<project cat='kern'>
<title>Intel wireless update</title>

<links>
<url href='https://lists.freebsd.org/mailman/listinfo/freebsd-wireless'>The freebsd-wireless mailing list</url>
</links>

<contact>
<person>
<name>Bjoern A. Zeeb</name>
<email>bz@FreeBSD.org</email>
</person>
</contact>

<h3>Newer Intel Wireless device support</h3>

<body><p>The Intel Wireless driver update project aims to bring support for
newer chipsets and also get station side to 11ac in a first step.
</p>
<p>During the last months connection code between net80211 and the
Linux driver KPI was implemented and scanning is working.
Currently the focus is on sending and driving one state machine
from the other and syncing state between net80211 and the
Linux compat code.
</p>
<p>In addition the driver and firmware was updated from upstream sources
to include support for the AX210 hardware generation, which was already
tested to attach.
</p>
<p>The hope is that by the time the status report gets published
authentication and association are working and basic data packet passing
will work soon.
</p>
<p>Sponsor: The FreeBSD Foundation
</p></body></project>
<project cat='kern'>
<title>Fenestras X random(4)</title>

<links>
<url href='https://svnweb.freebsd.org/base?view=revision&amp;revision=366620'>SVN revision 1/3</url>
<url href='https://svnweb.freebsd.org/base?view=revision&amp;revision=366621'>SVN revision 2/3</url>
<url href='https://svnweb.freebsd.org/base?view=revision&amp;revision=366622'>SVN revision 3/3</url>
<url href='https://aka.ms/win10rng'>FX Design (PDF)</url>
<url href='https://www.schneier.com/academic/fortuna/'>Fortuna Design</url>
</links>

<contact>
<person>
<name>Conrad Meyer</name>
<email>cem@FreeBSD.org</email>
</person>
<person>
<name>FreeBSD CSPRNG group</name>
<email>csprng@FreeBSD.org</email>
</person>
</contact>

<body><p>Since FreeBSD 11, the default <code>random(4)</code> implementation is based on the
<i>Fortuna</i> (2003) design by Ferguson and Schneier.  At a high level, <i>Fortuna</i>
accumulates entropy into a series of pools, and reseeds a single generator from
some of these pools according to some criteria.
</p>
<p>In 2019, Ferguson (at Microsoft) published a whitepaper on the design of the
<i>Windows 10</i> system random number generator.  <i>Fenestras X</i> is a <code>random(4)</code>
implementation based on the published <i>Windows 10</i> design.
</p>
<p>The <i>Fenestras X</i> / <i>Windows 10</i> design is similar to <i>Fortuna</i>, so it is
probably most interesting to describe their differences:
</p>
<ul>
<li><p><i>Fenestras X</i> has per-CPU generators seeded from a root generator.
    <i>Fortuna</i> only has the root generator.  This change eliminates lock
    contention between <code>random(4)</code> readers running on multiple cores.
</p></li>
<li><p>Generators in <i>Fenestras X</i> form a tree from the root RNG.  When read,
    generators efficiently check if their parent generator has been seeded with
    newer entropy.  If so, child generators reseed themselves before serving
    the read operation.  This is integrated with <code>arc4random(9)</code>, as well as
    userspace <code>arc4random(3)</code>.
</p></li>
<li><p><i>Fenestras X</i> generators are buffered.  Requests smaller than some
    arbitrary threshold (currently 128 bytes) are served from the buffer.
    Bytes read from the buffer are securely erased when they are consumed.  The
    buffer is refreshed if the request consumes more bytes than were available
    in the buffer.  This amortizes the cost of rekeying and generating output
    from a cryptographic CTR-mode cipher, which is especially slow with AES.
</p>
</li></ul>
There are other important differences, and readers interested in system CSPRNGs
<p>should read Ferguson's whitepaper.  It is short and accessible.  For more
information on the FreeBSD implementation, please see the SVN commit messages
— especially <code>r366620</code>.
</p>
<p>The <i>Fenestras X</i> implementation is available in <code>CURRENT</code>, but disabled by
default.  (The default remains <i>Fortuna</i>.)  At this time, you must set the
<code>RANDOM_FENESTRASX</code> option in your custom kernel configuration and rebuild your
kernel to use the new design.  There are no known bugs or weaknesses relative
to the <i>Fortuna</i> implementation.
</p>
<p>Future work and call to action:
</p>
<ul>
<li><p>Additional design review, implementation review, and testing is welcome.
</p></li>
<li><p>Additional entropy sources: we could use implementations of some of the
    sources described in the whitepaper, in both <i>Fortuna</i> and <i>Fenestras X</i>.
    In particular, we're missing a jitter entropy source.
</p></li></ul>
</body></project>
<project cat='kern'>
<title>pf performance improvement</title>

<links>
<url href='https://cgit.freebsd.org/src/commit/?id=1c00efe98ed7d103b9684ff692ffd5e3b64d0237'>First commit</url>
<url href='https://reviews.freebsd.org/D27707'>D27707</url>
<url href='https://reviews.freebsd.org/D27756'>D27756</url>
<url href='https://reviews.freebsd.org/D27757'>D27757</url>
<url href='https://reviews.freebsd.org/D27758'>D27758</url>
<url href='https://reviews.freebsd.org/D27759'>D27759</url>
<url href='https://reviews.freebsd.org/D27760'>D27760</url>
<url href='https://reviews.freebsd.org/D27761'>D27761</url>
<url href='https://reviews.freebsd.org/D27762'>D27762</url>
<url href='https://reviews.freebsd.org/D27763'>D27763</url>
<url href='https://reviews.freebsd.org/D27764'>D27764</url>
</links>

<contact>
<person>
<name>Kristof Provost</name>
<email>kp@freebsd.org</email>
</person>
</contact>

<body><p>The performance of pf was not as good as it could be. Some investigation with the
invaluable hwpmc tooling eventually pointed to very poor cache behaviour.
The longest_lat_cache.miss event was very informative.
</p>
<p>This turned out to be due to pf doing packet and byte counting in states, rules and
interfaces.
</p>
<p>The pf code took the very straightforward approach of having a simple uint64_t
variable and incrementing it for every packet. The downside of this is that
when multiple cores do it simultaneously the CPU ends up having to write this
to memory very often, slowing packet processing down greatly. Happily the
counter(9) framework is designed for this exact situation.
</p>
<p>One additional complication is that pf uses the same structure definitions for
its internal data as it uses for configuration from user space. To avoid
breaking user space these data structures have been decoupled. That is, where
pf_rule used to be used both to set rules via the ioctl() interface and to
evaluate rules while processing packets we now only use pf_rule for
configuration. The new pf_krule structure is used when evaluating packets.
This allows us to change the pf_krule structure, to change uint64_t to
counter_u64_t, without affecting user space.
</p>
<p>Olivier Cochard-Labbé tested the full set of changes, and found (depending on
hardware) <a href='http://dev.bsdrp.net/benchs/kp/pf-patches/'>substantial improvements in throughput</a>:
</p>
<p>Sponsor: Orange Business Services
</p></body></project>
<project cat='kern'>
<title>IP Routing lookup improvements</title>

<links>
<url href='https://reviews.freebsd.org/D27401'>Add modular routing lookup framework.</url>
</links>

<contact>
<person>
<name>Alexander Chernikov</name>
<email>melifaro@FreeBSD.org</email>
</person>
</contact>

<body><p>This work adds a fib lookup framework, allowing to attach custom IP lookup algorithms to any routing table on the fly. It allows to use more performant and efficient lookup algorithms, dynamically selected based on the number of routes in the routing table. Finally, it provides an implementation of modified DIR-24-8 for IPv4/IPv6, speeding IP lookups for the large-fib use case.
</p>
<p>This work is a part of a larger effort to modernise the routing subsystem.
</p>
<h3>Background</h3>

<p>FreeBSD runs diverse workloads on both low-end and high-end devices, resulting in different networking/memory requirements for each case.
Small boxes with a couple of routes are different from routers with full-view.
IPv4 lookups are different from IPv6 ones.
Conditions can change dynamically: one may easily reconfigure a system to receive full view instead of a default route.
</p>
<p>Currently, FreeBSD uses radix (compressed binary tree) to perform all unicast route manipulations, including routing lookups.
Radix implementation requires storing key length in each item, allowing to use sockaddrs, transparently supporting virtually any address family.
This flexibility comes at a cost: radix is <i>relatively slow</i>, <i>cache-unfriendly</i> and adds <i>locking</i> to the hot path.
Finally, radix is closely coupled to the rest of the system, making it hard to switch to something else.
</p>
<h3>Implementation overview</h3>

<h4>Overview</h4>

<p>Modular fib IP lookup framework has been designed to address flexibility and performance requirements.
</p>
<p>It keeps system radix as the "control plane" source of truth, simplifying actual algorithms implementation.
It allows dynamic load new algorithms as the kernel modules and abstracts most OS-specific details, reducing algorithm "glue" code.
It automatically adapts to the current system state by picking the best matching algorithm for the routing table on-the-fly.
</p>
<p>The following algorithms are provided by default.
</p>
<p>IPv4:
</p>
<ul>
<li><p>bsearch4 (lockless binary search in a specially-crafted IP array), tailored for small-fib (less than 16 routes)
</p></li>
<li><p>radix4_lockless (lockless immutable radix, re-created on every routing table change), tailored for small-fib (less than 1000 routes)
</p></li>
<li><p>radix4 (base system radix backend)
</p></li>
<li><p>dpdk_lpm4 (DPDK DIR24-8-based lookups), lockless datastructure optimised for large-fib ( <a href='https://reviews.freebsd.org/D27412'>D27412</a> )
</p>
</li></ul>
IPv6:

<ul>
<li><p>radix6_lockless: lockless immutable radix, re-created on every routing table change, tailored for small-fib (less than 1000 routes)
</p></li>
<li><p>radix6: wrapper around existing system radix
</p></li>
<li><p>dpdk_lpm6: DPDK DIR24-8-based lookups, lockless datastructure optimised for large-fib ( <a href='https://reviews.freebsd.org/D27412'>D27412</a> )
</p>
</li></ul>
<h4>Performance changes</h4>

<p>Micro benchmarks (i7-7660U, single-core lookups, 2048 destinations, benchmark code in <a href='https://reviews.freebsd.org/D27604'>D27604</a>).
</p>
<p>IPv4:
</p>
<ul>
<li><p>8 routes: radix4: ~20mpps, radix4_lockless: ~25mpps, bsearch4: ~69mpps, dpdk_lpm4: ~67 mpps
</p></li>
<li><p>700k routes: radix4_lockless: 3.3mpps, dpdk_lpm4: 46mpps
</p>
</li></ul>
IPv6:

<ul>
<li><p>8 routes: radix6_lockless: ~20mpps, dpdk_lpm6: ~70mpps
</p></li>
<li><p>100k routes: radix6_lockless: ~14mpps, dpdk_lpm6: ~57mpps
</p>
</li></ul>
Forwarding performance:

<ul>
<li><p>+10-15% IPv4: small-fib, bsearch4
</p></li>
<li><p>+25% IPv4: full-view, dpdk_lpm4
</p></li>
<li><p>+20% IPv6: full-view, dpdk_lpm6
</p>
</li></ul>
<h3>Status</h3>

<ul>
<li><p>Modular longest-prefix-match lookup algorithms (<a href='https://reviews.freebsd.org/D27401'>D27401</a>) [ DONE ]
</p><ul>
<li><p>Design control plane framework for attaching algorithms [ DONE ]
</p></li>
<li><p>Port DPDK IPv6 lockless lookup algorithm ( <a href='https://reviews.freebsd.org/D27412'>D27412</a>) [ DONE ]
</p></li>
<li><p>Port DPDK IPv4 lockless lookup algorithm ( <a href='https://reviews.freebsd.org/D27412'>D27412</a>) [ DONE ]
</p></li></ul>
</li></ul>
</body></project>
<project cat='kern'>
<title>Scalable routing multipath support</title>

<links>
<url href='https://reviews.freebsd.org/D24141#change-ZOjdMqgDgUr7'>Implementation of scalable multipath</url>
<url href='https://reviews.freebsd.org/D26449'>Introduce scalable route multipath</url>
</links>

<contact>
<person>
<name>Alexander Chernikov</name>
<email>melifaro@FreeBSD.org</email>
</person>
</contact>

<body><p>This work targets implementing scalable routing multipath support and enabling it by default.
It closes the long-standing feature gap with other modern networking OSes.
</p>
<p>This work is a part of on-going efforts to modernize the routing subsystem.
</p>
<h3>Background</h3>

<p>Initial FreeBSD multipath implementation, <code>RADIX_MPATH</code>, was added back in <a href='https://github.com/freebsd/freebsd-legacy/commit/4e8901ea7a04d2d803067647c0641e41494b8868'>2008</a>. It was based on the radix changes and represented multipath routes as a linked-list of chained paths. It was not fully finished and tested, resulting in many crash reports. 
</p>
<h3>Implementation overview</h3>

<p>Multipath-related change changes are based on the introduction of the concept of next hops. Nexthops are separate data structures, containing the necessary information to perform packet forwarding. They are shared among the routes, providing more pre-computed cache-efficient data while requiring less memory.
Interested readers can find a more detailed description in <a href='https://reviews.freebsd.org/D24141'>D24141</a>. They can find another overview in Nexthop objects <a href='https://linuxplumbersconf.org/event/4/contributions/434/attachments/251/436/nexthop-objects-talk.pdf'>talk</a> describing Linux kernel implementation.
</p>
<p>Multipath implementation extends the nexthop concept further by introducing nexthop groups. Nexthop group is simply an array of nexthops, compiled according to each nexthop relative weight.
</p>
<p>Each route has a pointer to either nexthops or a nexthop group, decoupling lookup algorithm from the routing stack internals. Both nexthops and nexthop groups are immutable and use epoch(9)-backed reclamation.
</p>
<h3>Status</h3>

<ul>
<li><p>Nexthop objects (<a href='https://reviews.freebsd.org/D24232'>D24232</a>) [ DONE ]
</p><ul>
<li><p>Introduction of nexthop objects [ DONE ]
</p></li>
<li><p>Conversion of old KPI users to the new one [ DONE ]
</p><ul>
<li><p>Conversion of route caching to nexthop caching [ DONE ]
</p></li></ul>
</li><li><p>Conversion of struct <code>rtentry</code> field access to nhop field access [ DONE ]
</p></li>
<li><p>Eliminating old lookup KPI and hiding struct rtentry [ DONE ]
</p>
</li></ul>
</li><li><p>Multipath routing (<a href='https://reviews.freebsd.org/D26449'>D26449</a>) [ DONE ]
</p><ul>
<li><p>Switch control plane customers to use (rtentry, nexthop) pairs instead of rtentry to allow multipath changes happen transparently [ DONE ]
</p></li>
<li><p>Introduce nexthop group objects [ DONE ]
</p></li>
<li><p>Add multipath support for the rib (routing information base) manipulation functions [ DONE ]
</p></li>
<li><p>Add flowid generation for outbound traffic to enable load balancing [ DONE ]
</p>
</li></ul>
</li><li><p>Routing daemon support
</p><ul>
<li><p>Add net/bird support for multipath routing [ NOT STARTED ]
</p></li>
<li><p>Add explicit nexthop/nexthop groups control via rtsock [ IN PROGRESS ]
</p></li>
<li><p>Work with FRR developers to add nexthop-based route control [ NOT STARTED ]
</p></li></ul>
</li></ul>
</body></project>
<project cat='kern'>
<title>Thunderbolt3/USB4 stack</title>

<contact>
<person>
<name>Scott Long</name>
<email>scottl@freebsd.org</email>
</person>
</contact>

<body><p>This project implements a driver stack for Thunderbolt3 and USB4.  These
technologies differ radically from USB3 and prior, and require completely new
drivers for the host interface adapter and topology as well as configuration
management layers.  At their most fundamental level, a TBT3/USB4 topology
appears as PCI bridges and buses, and attached devices appear as either PCI
devices, USB3 devices, or DisplayPort devices.  Early TBT3 controllers don't
even appear in the system topology unless a TBT3 device is plugged in.  These
early TBT3 systems also implement a security policy meant to protect against
unauthorised or malicious devices, though that scheme has been proven to not
be effective and has been removed from later TBT3 and USB4 implementations.
Besides security control, the TBT3/USB4 stack controls power management and
topology hotplug.
</p>
<p>The FreeBSD driver currently supports Alpine Ridge and Ice Lake TBT3
controllers, and can perform basic security validation and topology awareness.
USB4 support as well as full connection manager and power management support is
still being worked on.  The current driver will be committed to FreeBSD in
early January 2021.
</p>
<p>Though this work is not sponsored, it has been done with the encouragement and
support of the FreeBSD Foundation and Netgate.
</p></body></project>
<project cat='kern'>
<title>Vectored AIO</title>

<contact>
<person>
<name>Alan Somers</name>
<email>asomers@FreeBSD.org</email>
</person>
</contact>

<body><p>POSIX AIO is a facility for asynchronous I/O to files and devices.  FreeBSD's
implementation is efficient, especially when writing to disk files.  But a
long-standing defect in the standard API is a lack of vectored functions.  That
is, there is no asynchronous equivalent of <code>pwritev(2)</code> and <code>preadv(2)</code>.  A
common workaround is to use <code>lio_listio(2)</code> instead.  However, that has several
drawbacks.  It's more effort for the programmer, it might return early with
only a subset of the operations completed, it requires more total syscalls, and
there is no guarantee that the operations will complete in-order.
</p>
<p>This quarter I added two new syscalls: <code>aio_writev(2)</code> and <code>aio_readv(2)</code>.
They work just like their non-vectored counterparts, but they take an array of
<code>iovec</code> elements, just like <code>pwritev</code> and <code>preadv</code>.  You can't use them in
combination with <code>lio_listio</code>, but that could be added in the future.
</p></body></project>
<project cat='kern'>
<title>ZSTD Compression in ZFS</title>

<contact>
<person>
<name>Allan Jude</name>
<email>allanjude@freebsd.org</email>
</person>
</contact>

<body><p>Zstandard (ZSTD) is a modern high-performance compression
algorithm designed to provide the compression ratios of gzip
while offering much better performance. ZSTD has been adopted
in FreeBSD for a number of other uses, including compressing
kernel crash dumps, as a replacement for gzip or bzip for
compressing log files, and for future versions of pkg(8).
</p>
<p>This effort to complete the integration of ZSTD into ZFS is
funded by the FreeBSD Foundation.
</p>
<p>During the four quarter the final tasks in the project to integrate
ZSTD into OpenZFS were completed.
</p>
<p>Completed milestones in this project:
</p>
<ul>
<li><p>Integrated ZSTD in the FreeBSD boot loader (Warner Losh <a href='mailto:imp@freebsd.org'>imp@freebsd.org</a>)
</p></li>
<li><p>Added a section to the FreeBSD Handbook ZFS chapter explaining ZSTD
</p></li>
<li><p>Wrote a FreeBSD Journal Article explaining considerations when selecting a suitable compression level
</p></li>
<li><p>Monitored for bug reports after the changes were integrated into -CURRENT
</p>
</li></ul>
With all of these changes in place, it is now possible to boot from pools
<p>compressed with zstd or zstd-fast. For comparison, a standard installation of
FreeBSD 13 (without debug symbols) uncompressed is 1175 MB, and when compressed
with LZ4, is only 570 MB (2.15x) but when compressed with ZSTD's default level
of 3 is only 417 MB (3.00x), and with the maximum level, 19,
only 374 MB (3.36x).
</p>
<p>Sponsor: The FreeBSD Foundation<br />
</p></body></project>
<project cat='arch'>
<title>arm64 platform updatesq</title>

<contact>
<person>
<name>Mitchell Horne</name>
<email>mhorne@FreeBSD.org</email>
</person>
</contact>

<body><p>In the interest of seeing the arm64 architecture promoted to Tier-1 status, an
effort was undertaken to test building and serving of release and patch-level
updates via <code>freebsd-update(1)</code>. The conclusion of this investigation is that
the process works with very few changes required; a small tweak is needed for
the update build scripts, and a minor bugfix in the <code>bsdiff(1)</code> utility was
committed. The hope is that the project can begin providing security updates for
the platform with the release of FreeBSD 13.0, removing the requirement that
users compile these updates from source.
</p>
<p>Added this quarter was arm64 support for the new <code>ossl(4)</code> crypto driver. This
driver provides acceleration of SHA-1 and SHA-2 cryptographic operations by
leveraging OpenSSL's assembly routines. These routines will detect and use
optimized instructions, as supported by the CPU. This support benefits userland
applications via the <code>cryptodev(4)</code> device, and in-kernel consumers of the
<code>crypto(9)</code> interface, such as the IPSec Authentication Header protocol and
kernel TLS.
</p>
<p>Finally, work was done to add the necessary machine-dependent bits for the
kernel's <code>gdb(4)</code> interface. This enables remote debugging of the kernel with
<code>gdb(1)</code> over a serial line.
</p>
<p>Sponsor: The FreeBSD Foundation
</p></body></project>
<project cat='arch'>
<title>FreeBSD/RISC-V Project</title>

<links>
<url href='https://wiki.freebsd.org/riscv'>Wiki</url>
</links>

<contact>
<person>
<name>Mitchell Horne</name>
<email>mhorne@FreeBSD.org</email>
</person>
</contact>
<body><p>Contact: <a href='https://lists.FreeBSD.org/mailman/listinfo/freebsd-riscv'>freebsd-riscv Mailing List</a><br />
Contact: IRC #freebsd-riscv on freenode<br />
</p>
<p>The FreeBSD/RISC-V project is providing support for running FreeBSD on the
<a href='https://riscv.org/'>RISC-V Instruction Set Architecture</a>.
</p>
<p>This quarter saw a number of improvements and bugfixes from committers and
contributors alike. A few small items from this quarter:
</p>
<ul>
<li><p>Added riscv64 LINT kernel config plus CI job (<code>FreeBSD-head-riscv64-LINT</code>)
</p></li>
<li><p>Switched <code>emulators/riscv-isa-sim</code> to official upstream and updated to
    2020-11-02 snapshot
</p></li>
<li><p>Created <code>sysutils/u-boot-sifive-fu540</code>, a u-boot port for the HiFive
    Unleashed
</p></li>
<li><p>Improved SBI extension support
</p>
</li></ul>
Further progress was made this quarter in building ports for RISC-V. Build and
<p>runtime issues with large dependencies <code>devel/python-setuptools</code> and
<code>devel/glib20</code> were fixed, enabling several thousand skipped ports. There is
some in-progress work to address failures in other significant ports, such as
<code>devel/nspr</code> and <code>databases/sqlite3</code>. By addressing some of these small-effort
issues, some 15000+ ports can now be built for the platform with
qemu-user-static.
</p>
<p>Finally, December saw the arrival of the first <code>riscv64</code> weekly development
snapshots. This includes the usual memstick installer, a virtual machine image,
and a generic SD card image. There are still some minor tweaks to be made, but
this marks a significant step forward for the platform, and lowers the barrier
of entry for running a FreeBSD/RISC-V system. This also means that FreeBSD 13
will likely be the first downloadable release for the architecture. For those
interested in trying out the VM image for themselves, see <url href='https://wiki.freebsd.org/riscv#Quick_Start'>the Quick Start instructions</url>
on the wiki.
</p></body></project>
<project cat='bin'>
<title>Dual-stack ping command</title>

<contact>
<person>
<name>Alan Somers</name>
<email>asomers@FreeBSD.org</email>
</person>
</contact>

<body><p>The venerable ping command has until now only supported IPv4.  A separate
utility, ping6, was originally written by WIDE as a research tool to develop
IPv6.  As a research tool, it didn't need IPv4 support, but since then, it's
been put to practical use by countless developers and sysadmins everywhere.
</p>
<p>The ping/ping6 split has been a perennial complaint.  It's annoying that two
separate commands are needed, even though they do almost exactly the same
thing.  This quarter, I merged Ján Sučan's GSoC work, which merged the two
commands.  Now ping can handle either protocol, based on the -4 and -6
switches, or based on the format of the target.  A ping6 hard link is provided
for backwards compatibility.
</p>
<p>Sponsor: Google Summer of Code<br />
</p></body></project>
<project cat='doc'>
<title>FreeBSD Translations on Weblate</title>

<links>
<url href='https://wiki.freebsd.org/DocTranslationOnWeblate'>Translate FreeBSD on Weblate wiki</url>
<url href='https://translate-dev.freebsd.org/'>FreeBSD Weblate Instance</url>
</links>

<contact>
<person>
<name>Danilo G. Baio</name>
<email>dbaio@FreeBSD.org</email>
</person>
<person>
<name>Edson Brandi</name>
<email>ebrandi@FreeBSD.org</email>
</person>
</contact>

<body><p>In search of new contributors an article was published in the
September/October 2020 issue of the FreeBSD Journal about How to Become a
FreeBSD Translator.
</p>
<p>During the whole year we received new contributors to the effort; numbers are
still growing and we are receiving translations almost daily on our Weblate
platform.
</p>
<h3>Q4 2020 Status</h3>

<ul>
<li><p>11 languages (1 new language)
</p></li>
<li><p>116 registered users (69 new users since 2020q1)
</p>
</li></ul>
<h4>Languages</h4>

<ul>
<li><p>Chinese (Simplified) (zh_CN)
</p></li>
<li><p>Chinese (Traditional) (zh_TW)
</p></li>
<li><p>Dutch (nl_NL) - Added
</p></li>
<li><p>French (fr_FR)
</p></li>
<li><p>German (de_DE)
</p></li>
<li><p>Italian (it_IT)
</p></li>
<li><p>Norwegian (nb_NO)
</p></li>
<li><p>Persian (fa_IR)
</p></li>
<li><p>Portuguese (pt_BR)
</p></li>
<li><p>Spanish (es_ES)
</p></li>
<li><p>Turkish (tr-TR)
</p>
</li></ul>
We want to thank everyone that contributed, translating or reviewing documents.

<p>And please, help promote this effort on your local user group, we always need
more volunteers.
</p></body></project>
<project cat='doc'>
<title>DOCNG on FreeBSD</title>

<links>
<url href='https://gitlab.com/carlavilla/freebsd-hugo-website'>DOCNG Website Repo</url>
<url href='https://gitlab.com/carlavilla/freebsd-hugo-documentation'>DOCNG Documentation Repo</url>
<url href='https://gitlab.com/carlavilla/freebsd-hugo-data'>DOCNG Share Repo</url>
</links>

<contact>
<person>
<name>Sergio Carlavilla</name>
<email>carlavilla@FreeBSD.org</email>
</person>
</contact>

<body><p>The Doc New Generation project is finished. The switch-over date will be Saturday, January 23rd.
</p>
<p>The objective of using Hugo and AsciiDoctor is to reduce the
learning curve and let people to start quickly contributing to our documentation
system. Other benefits of using Hugo is that we can use other
technologies aside from AsciiDoctor, like MarkDown, RST, Pandoc, etc.
</p>
<p>You can find a <a href='https://github.com/sergio-carlavilla/documentation-project-primer'>work in progress on updating the FreeBSD Documentation Project Primer to Hugo/AsciiDoctor</a>.
</p></body></project>
<project cat='ports'>
<title>KDE on FreeBSD</title>

<links>
<url href='https://freebsd.kde.org/'>KDE FreeBSD</url>
<url href='https://community.kde.org/FreeBSD'>KDE Community FreeBSD</url>
</links>

<contact>
<person>
<name>Adriaan de Groot</name>
<email>kde@FreeBSD.org</email>
</person>
</contact>

<body><p>The KDE on FreeBSD project aims to package all of the software
produced by the KDE Community for the FreeBSD ports tree.
The software includes a full desktop environment called KDE Plasma,
graphics applications, instant-messengers, a video-editing suite,
as well as a tea timer
and hundreds of other applications that can be used on
any FreeBSD machine.
</p>
<p>The KDE team (kde@) is part of desktop@ and x11@ as well,
building the software stack to make FreeBSD beautiful and usable
as a daily-driver graphics-based desktop machine.
</p>
<p>This quarter the kde@ team:
</p>
<ul>
<li><p>Landed the October, November and December updates to KDE Applications
and to KDE Plasma
</p></li>
<li><p>Landed all of the bi-weekly KDE Frameworks releases
</p></li>
<li><p>Updated Qt to 5.12.2, including Qt5 WebEngine
</p></li>
<li><p>Followed up with two cmake patch releases
</p></li>
<li><p>Followed up one ninja patch release
</p>
</li></ul>
There was lots of infrastructural work and individual application
<p>updates and a new Matrix client from the KDE community
as well, which we typically fail to administer and write about
so this report is fairly short with mostly big-ticket items.
We had fun, we chased the things that are most useful to
us, and got through the year. Here's to next year with
actually seeing FreeBSD people again.
</p>
<p>I (adridg@) would like to especially thank Kai Knoblich (kai@) for chasing WebEngine:
that's a huge and painful codebase to deal with, and here we
are, all up-to-date.
</p></body></project>
<project cat='ports'>
<title>FreeBSD Office team</title>

<links>
<url href='https://wiki.freebsd.org/Office'>The FreeBSD Office project</url>
</links>

<contact>
<person>
<name>FreeBSD Office team ML</name>
<email>office@FreeBSD.org</email>
</person>
<person>
<name>Dima Panov</name>
<email>fluffy@FreeBSD.org</email>
</person>
<person>
<name>Li-Wen Hsu</name>
<email>lwhsu@FreeBSD.org</email>
</person>
</contact>


<body><p>The FreeBSD Office team works on a number of office-related software suites
and tools such as OpenOffice and LibreOffice.<br />
</p>
<p>Work during this quarter focused on providing the latest stable release of
LibreOffice suite and companion apps to all FreeBSD users.
</p>
<p>Latest and quarterly ports branches got a series of updates of the LibreOffice suite
from 7.0.1 thru 7.0.4 releases, compilation patches for all Tier 1 architectures,
and updates of all companion libraries. Some of our local and critical to build patches
were sent to and accepted by upstream.
</p>
<p>Meanwhile, our WIP repository was moved to new home under official github.org/freebsd resources.
</p>
<p>The WIP repository also has a major update with development versions of the LibreOffice suite,
version 7.1.0.0.beta1 for now. Release will be planned in March, 2021.
</p>
<p>We are looking for people to help the project.
All unstable work with LibreOffice snapshots is staged in our <a href='https://github.com/freebsd/freebsd-ports-libreoffice'>WIP repository</a>.<br />
The <a href='https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=open&amp;email1=office%40FreeBSD.org&amp;emailassigned_to1=1&amp;emailcc1=1&amp;emailreporter1=1&amp;emailtype1=substring&amp;query_format=advanced&amp;list_id=374316'>open bugs list</a>
contains all filed issues which need some attention.
Patches, comments and objections are always welcome in the mailing list and bugzilla.
</p>
</body></project>
<project cat='ports'>
<title>Ports On Non-x86 Architectures</title>

<contact>
<person>
<name>Mark Linimon</name>
<email>linimon@FreeBSD.org</email>
</person>
</contact>

<body><p>It has been some time since the last report on the status of FreeBSD
ports on non-x86 architectures.
</p>
<p>Traditionally, we have referred to these as "tier-2 architectures".
However, aarch64 and powerpc64 have aspirations for tier-1.  Also,
although riscv64 is currently tier-3, it has aspirations for tier-2.
</p>
<ul>
<li><p>The big news is that, thanks to the FreeBSD Foundation (and the
    assistance of Philip Paeps), FreeBSD now has two new aarch64 boxes,
    which have replaced the previous, badly-aging, alternatives.  For
    the first time since August, we once again have up-to-date aarch64
    packages.
</p></li>
<li><p>Thanks to the above, and the work of Emmanuel Vadot and others, some
    bitrot in aarch64 ports has been reversed.
</p></li>
<li><p>Piotr Kubaj (pkubaj@) continues QA on powerpc64 (big-endian) ports.
    Almost everything that is buildable now does so.  The Linux ports and
    some of the graphics drivers are excluded.  Otherwise, powerpc64 is
    up to parity with amd64.
</p></li>
<li><p>Piotr has also begun the task of bringing powerpc64le (little-endian)
    up to parity with powerpc64.  Although several of the powerpc64 src
    committers (and your author) have a fondness for big-endian, the fact
    is that our most feasible path to getting graphics capability anywhere
    near parity with x86 is via the little-endian choice.
</p></li>
<li><p>Mark Linimon (linimon@) has begun his own test-builds of ports on
    riscv64 just to ascertain overall buildability.  Surprisingly, many
    ports do indeed build.  Thanks to contributions from several people
    already working on riscv64, including John Baldwin (jhb@) with an LLVM
    fix, we are now able to build around 20,000 packages.  NB: these packages
    are <i>unofficial</i> and not guaranteed.
</p></li>
<li><p>The work of Kyle Evans (kevans@) on chasing bitrot in qemu has been key
    to work on both aarch64 and riscv64.  All users are encouraged to
    update to the latest version.
</p></li>
<li><p>Unfortunately mips/mips64 are badly in need of work.  The fact that
    devel/libffi does not build on mips64 blocks nearly half the ports
    tree.
</p>
</li></ul>
Tasklist:

<ul>
<li><p>We need users of riscv64 to actually test the packages that have been
    built (so far, they have only been tested for buildability).  Contact
    linimon@ if you are interested.
</p>
</li>
<li><p>If anyone is still using mips/mips64 for other than the most trivial
    tasks, we would welcome patches.
</p></li></ul>
</body></project>
<project cat='ports'>
<title>Python 2.7 removal from Ports</title>

<links>
<url href='https://www.FreeBSD.org/ports/'>About FreeBSD Ports</url>
<url href='https://www.freebsd.org/portmgr/index.html'>Ports Management Team</url>
<url href='https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249337'>[meta] Ports broken by Python 2.7 End-of-Life and removal</url>
</links>

<contact>
<person>
<name>René Ladan</name>
<email>portmgr-secretary@FreeBSD.org</email>
</person>
<person>
<name>FreeBSD Ports Management Team</name>
<email>portmgr@FreeBSD.org</email>
</person>
</contact>

<body><p>As of January 2020, Python 2.7 reached its end-of-life after several years of extensions.
Portmgr subsequently started the project of phasing Python 2.7 out of the Ports Tree by tagging lang/python27 for expiration on 2020-12-31.
Last year, some 740 ports were removed from the Ports Tree as they were incompatible with Python 3, mostly because these ports were either unmaintained or abandoned upstream.
</p>
<p>During this process, there were several instances of an upstream still being active but where the upstream have not had the resources yet to upgrade their software to Python 3.
A noticeable example of this is www/chromium and derived software, such as devel/electron7 and www/qt5-webengine.
Portmgr is currently looking into ideas on how to minimize the impact of Python 2.7 on the Ports Tree while keeping Chromium and KDE 5 functional.
As various software packages on the FreeBSD cluster itself also use Python 2.7, portmgr started coordinating with affected parties on upgrade plans.
Currently there are 40 ports left that directly depend on Python 2.7 to build or run, and an unknown number of indirect ports.
All those ports should eventually be upgraded to Python 3 or be removed too, ideally some time this year.
</p>
<p>Portmgr is currently cleaning up (unused) Python 2.7 code from ports which do not need Python 2.7.
New ports should not be using Python 2.7 anymore, i.e. they should not have USES=python but instead something like USES=python:3.6+.
</p>
<p>So while this all looks rather invasive, it is not feasible to keep Python 2.7 around for much longer.
Over time security vulnerabilities might show up which will likely no longer be fixed, because the Python Software Foundation no longer supports Python 2.7.
Other problems are that the software gets outdated over time and thereby loses its usefulness as part of a development kit.
</p>
<p>Help needed:
</p>
<ul>
<li><p>Coordinate with postmaster on isolating or migrating away from mail/mailman
</p></li>
<li><p>Coordinate with clusteradm (?) for upgrading svnweb and our wiki
</p></li></ul>
</body></project>
<project cat='ports'>
<title>Xfce on FreeBSD</title>

<links>
<url href='https://xfce.org/about/news/?post=1608595200'>Xfce 4.16 Upstream Release Announcement</url>
<url href='https://www.freshports.org/x11-wm/xfce4'>Xfce meta-port on FreshPorts</url>
</links>

<contact>
<person>
<name>Xfce team</name>
<email>xfce@FreeBSD.org</email>
</person>
<person>
<name>Guido Falsi</name>
<email>madpilot@FreeBSD.org</email>
</person>
</contact>

<body><p>The FreeBSD Xfce team (xfce@) work to ensure the Xfce desktop environment
is maintained and fully functional on FreeBSD.
</p>
<p>This quarter the Xfce team are pleased to welcome Xfce 4.16
to the FreeBSD ports tree!
</p>
<p>Some of the highlights of this Xfce 4.16 release:
</p>
<ul>
<li><p>The panel now supports dark mode (enabled by default) and an animated autohide transition
</p></li>
<li><p>A new panel plugin dubbed "statustray" which combines both StatusNotifier and legacy Systray items
</p></li>
<li><p>Fractional scaling support was added to the display dialog (helpful on HiDPI displays)
</p></li>
<li><p>A new tab in the "About Xfce" dialog shows basic system information like CPU or GPU type
</p></li>
<li><p>The settings manager has improved search and filter capabilities
</p></li>
<li><p>All settings dialogs now use window decorations drawn by Gtk (client side decorations)
</p></li>
<li><p>The "Mime Settings" and "Preferred Applications" dialogs were merged into the "Default Applications" dialog
</p></li>
<li><p>The Thunar file manager now supports pause for copy/move operations, and queued file transfer
</p></li>
<li><p>Generating thumbnails for .epub (e-book format) was added to tumbler
</p></li>
<li><p>A new default wallpaper and icon theme
</p></li>
<li><p>The application finder now allows for sorting applications by "frecency" - a combination of frequency and recency
</p></li>
<li><p>Dropped GTK2 support from all components and plugins
</p>
</li></ul>
For further details, refer to the <a href='https://xfce.org/about/news/?post=1608595200'>Xfce 4.16 upstream release announcement</a>.

<p>Due to GTK2 and libxfce4gui support being removed, some panel plugins
and libraries will be removed since they no longer work with Xfce 4.16:
</p>
<ul>
<li><p>deskutils/orage
</p></li>
<li><p>deskutils/xfce4-volumed
</p></li>
<li><p>print/xfce4-print
</p></li>
<li><p>science/xfce4-equake-plugin
</p></li>
<li><p>x11/xfce4-embed-plugin
</p></li>
<li><p>x11/xfce4-quicklauncher-plugin
</p></li>
<li><p>x11/xfce4-wmdock-plugin
</p></li>
<li><p>x11-toolkits/libxfce4gui
</p>
</li></ul>
WARNING: Unfortunately this update can reveal a bug in pkg which can
<p>cause files from the libexo package to be absent after upgrade.
To avoid the issue, upgrade the libexo package by itself before
the rest of the packages, as described in UPDATING entry 20210102.
</p>
<p>Thanks also to riggs@, Olivier Duchateau <a href='mailto:duchateau.olivier@gmail.com'>duchateau.olivier@gmail.com</a>,
woodsb02@, Sergey Dyatko <a href='mailto:sergey.dyatko@gmail.com'>sergey.dyatko@gmail.com</a>, and ehaupt@ for their help and
contributions.
</p></body></project>
<project cat='third'>
<title>FreeBSD Aarch64 under VMWare ESXi-ARM Fling</title>

<links>
<url href='https://flings.vmware.com/esxi-arm-edition'>ESXi-ARM Fling</url>
<url href='https://vincerants.com/freebsd-under-vmware-esxi-on-arm-fling/'>FreeBSD Under VMWare ESXi-ARM Fling</url>
<url href='https://vincerants.com/freebsd-on-esxi-arm-fling-fixing-virtual-hardware/'>FreeBSD on ESXi-ARM Fling: Fixing Virtual Hardware</url>
<url href='https://vincerants.com/open-vm-tools-on-freebsd-under-vmware-esxi-arm-fling/'>open-vm-tools for FreeBSD VMWare ESXi-ARM Fling</url>
</links>

<contact>
<person>
<name>Vincent Milum Jr</name>
<email>freebsd@darkain.com</email>
</person>
</contact>

<body><p>VMWare is a company that produces a commercial hypervisor known
as vSphere ESXi for AMD64 and i386. In early October, they
released a tech demo hypervisor for ARM Aarch64 which runs
on ARM ServerReady hardware as well as single board computers
such as the Raspberry Pi 4b (4GB and 8GB models). This new
hypervisor is known as VMWare ESXi-ARM Fling.
</p>
<p>Since the release of ESXi-ARM Fling, work has been done on
both the hypervisor as well as FreeBSD, to make the two more
compatible with one another. Even though the work was
initially done to make these two work better together, the
work overall has been more general purpose for FreeBSD
in support of both bare-metal Aarch64 installations as well
as running FreeBSD under other hypervisors such as QEMU.
</p>
<p>An example of others building off of this work is <url href='https://twitter.com/astr0baby/status/1343354762964717568'>Twitter user astr0baby getting FreeBSD working under QEMU on a new Apple M1 system</url>.
</p>
<p>When ESXi-ARM Fling first released, to get FreeBSD to work
under it, the process required taking the Aarch64 premade
VMDK file, uploading it to the hypervisor storage, and then
running a series of CLI commands to convert the disk image
to a supported file format. The initial work done was to
get the FreeBSD Aarch64 ISO bootable and with the required
drivers to complete the install process. With this, users
can do fresh installs of FreeBSD Aarch64 using the same
methods they would use for AMD64 or i386 under ESXi.
</p>
<p>The CD-ROM driver's inclusion into FreeBSD 12 barely missed
the cut-off date for 12.2-RELEASE. However, the very first
12.2-STABLE build published for Aarch64 includes the CD-ROM
driver. FreeBSD 13-CURRENT also includes this driver. Due
to this, only 12-STABLE and 13-CURRENT support fresh CD ISO
installations.
</p>
<p>The next step was getting the major pieces of virtual
hardware working. This included adding more USB controllers,
the vmxnet virtual network card, and pvscsi para-virtual
SCSI drivers added to Aarch64 GENERIC.
</p>
<p>There is a known bug in ESXi-ARM Fling's virtual UEFI that
prevents booting from pvscsi, so for the time being the boot
device must be on a virtual disk attached to the SATA
controller inside the VM.
</p>
<p>ESXi-ARM Fling uses a new virtual SVGA device which
currently does not have working drivers on any platform, as
the specifications are not finalized yet. Due to this, only
efi-fb/scfb is available for console and Xorg for the time
being.
</p>
<p>The VMCI driver is currently not compiling at all. This
driver has sections of x86 assembly code that will need to be
converted over to ARM. This would be a great area for
anyone to look into that is experienced with converting assembly
language!
</p>
<p>At ESXi-ARM Fling launch, there was a hypervisor bug
preventing more than 1 vCPU from working inside FreeBSD.
This has since been fixed, allowing up to 8 vCPUs. Going
beyond this requires a <a href='https://github.com/freebsd/freebsd-src/compare/master...claplace:user/claplace/gicv3_mbi'>a patch to FreeBSD</a>,
which was authored by VMWare developer Cypou.
</p>

<p>Things that are currently fixed/working:
</p>
<ul>
<li><p>Booting from CD ISO image
</p></li>
<li><p>Virtual USB 2.0 controller
</p></li>
<li><p>Virtual USB 3.1 controller
</p></li>
<li><p>Virtual USB Keyboard
</p></li>
<li><p>Virtual USB Mouse
</p></li>
<li><p>vmxnet3 Virtual Network Card
</p></li>
<li><p>pvscsi Para-Virtual SCSI Storage Controller
</p></li>
<li><p>open-vm-tools Guest Virtual Machine Tools
</p></li>
<li><p>Xorg Enhanced Mouse Driver (untested)
</p></li>
<li><p>Multi-Core CPU (up to 8 vCPUs inside guest)
</p>
</li></ul>
Things that are still broken:

<ul>
<li><p>Booting from pvscsi
</p></li>
<li><p>Xorg SVGA Driver
</p></li>
<li><p>vmci Virtual Machine Communication Interface
</p></li>
<li><p>Multi-Core CPU (more than 8 vCPUs)
</p>

</li></ul>
With all of this done, it has made working on the Aarch64 ports
<p>collection easier by having a high quality virtualization
environment for development and testing. This environment
has already been used to update the ZeroTier port and
Facebook's RocksDB used in the MariaDB port.
</p>
<p>FreeBSD now has a Discord chat! Discussion about FreeBSD
on Aarch64 in general takes place in our
<a href='https://discord.gg/KHtrpdqE4F'>#embedded</a> channel. Despite
the name, we discuss all levels of ARM development, from
large servers, to virtualized environments, all the way down
to single board computers.
</p></body></project>
<project cat='third'>
<title>Bastille</title>

<links>
<url href='https://github.com/bastillebsd/bastille'>Bastille GitHub</url>
<url href='https://gitlab.com/bastillebsd-templates'>Bastille Templates</url>
<url href='https://bastillebsd.org'>Bastille Website</url>
</links>

<contact>
<person>
<name>Christer Edwards</name>
<email>christer.edwards@gmail.com</email>
</person>
</contact>

<h3>What is Bastille?</h3>

<body><p>Bastille is an open-source system for automating deployment and management of
containerised applications on FreeBSD.
</p>
<p>Bastille Templates automate container setup allowing you to easily reproduce
containers as needed.
</p>
<p>Bastille is available in ports as <code>sysutils/bastille</code>.
</p>
<h3>Q4 2020 Status</h3>

<p>In Q4 2020 Bastille merged some exciting new features. Changes include:
</p>
<ul>
<li><p>full adoption of the previously experimental Bastillefile format
</p></li>
<li><p>new <code>config</code> sub-command
</p></li>
<li><p>default templates included and applied by default
</p></li>
<li><p>support for -CURRENT jails on -CURRENT hosts
</p></li>
<li><p>support for 32bit containers on 64bit hosts
</p></li>
<li><p>support in templates for dynamic arguments &amp; defining variables
</p></li>
<li><p>over two dozen bug fixes and general improvements
</p>
</li></ul>
More details about <a href='https://github.com/BastilleBSD/bastille/releases'>Bastille Releases</a>.

<p>upstream was updated to <code>0.8.202010101</code> (latest).
ports (<code>sysutils/bastille</code>) was updated to <code>0.7.20200414</code>.
</p></body></project>
<project cat='third'>
<title>CheriBSD</title>

<links>
http://www.cheri-cpu.org
https://github.com/CTSRD-CHERI/cheribsd
https://www.morello-project.org
https://morello-dist.cl.cam.ac.uk
https://developer.arm.com/architectures/cpu-architecture/a-profile/morello
</links>

<contact>
<person>
<name>Alex Richardson</name>
<email>arichardson@FreeBSD.org</email>
</person>
<person>
<name>Andrew Turner</name>
<email>andrew@FreeBSD.org</email>
</person>
<person>
<name>Brooks Davis</name>
<email>brooks@FreeBSD.org</email>
</person>
<person>
<name>Edward Tomasz Napierala</name>
<email>trasz@FreeBSD.org</email>
</person>
<person>
<name>George Neville-Neil</name>
<email>gnn@FreeBSD.org</email>
</person>
<person>
<name>Jessica Clarke</name>
<email>jrtc27@FreeBSD.org</email>
</person>
<person>
<name>John Baldwin</name>
<email>jhb@FreeBSD.org</email>
</person>
<person>
<name>Robert Watson</name>
<email>rwatson@FreeBSD.org</email>
</person>
<person>
<name>Ruslan Bukin</name>
<email>br@FreeBSD.org</email>
</person>
</contact>

<body><p>CheriBSD extends FreeBSD to implement memory protection and software
compartmentalization features supported by the CHERI instruction-set
extensions.  There are three architectural implementations of the
CHERI protection model: CHERI-MIPS, CHERI-RISC-V, and Arm's forthcoming
experimental Morello processor (due late 2021).  CheriBSD is a research
operating system with a stable baseline implementation into which
various new research features have been, or are currently being, merged:
</p>
<ul>
<li><p>Arm Morello - In October, we released a developer preview of CheriBSD
ported to Arm's Morello architecture.  This release supports a
dynamically linked runtime and is generally functional.  It was cut
 from a development branch and work is in progress to merge the contents
 of this branch with the CheriBSD main line.  We anticipate producing a
new release from this branch in early 2021.
</p></li>
<li><p>Kernel spatial memory safety (pure-capability kernel) - The current
 CheriBSD kernel is a hybrid C program where only pointers to userspace
are CHERI capabilities. This ensures that the kernel follows the
intent of the application runtime and cannot be used to defeat
bounds on application pointers. We have developed and will soon
merge a pure-capability kernel where all pointers in the kernel are
 appropriately bounded capabilities. This vastly reduces the opportunity
for buffer overflows. This spatial memory safety lays the
groundwork for future work such as device driver compartmentalization
and kernel temporal safety.
</p></li>
<li><p>Userspace heap temporal memory safety (Cornucopia) - CHERI
capabilities provide the necessary features to enable
 robust and efficient revocation of freed pointers.  With <a href='https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/2020oakland-cornucopia.pdf'>Cornucopia</a>
we have implemented a light-weight revocation framework providing
 protection from use-after-reallocation bugs with an average cost below
 2%.  We aim to bring these overheads down further over the next year and
merge this functionality into the mainline CheriBSD.
</p></li>
<li><p>Syncing with upstream FreeBSD - We spent considerable time this
quarter catching up with FreeBSD-CURRENT.  As of the beginning of
December, we had caught up.  Merges are currently paused while we
work to land Morello and pure-capability kernel changes.  In the
interim, we have performed a test merge between our tree based on
the legacy export of the FreeBSD tree to git and the new FreeBSD
git repository.  The process went smoothly and is expected to have
few impacts.
</p></li>
<li><p>We have been working on updating the arm64 bhyve from Politehnica
University of Bucharest to have it committed to FreeBSD. We have been
upstreaming initial changes to help support this.
</p></li></ul>
</body></project>
<project cat='third'>
<title>Embedded Lab Project</title>

<links>
<url href='https://www.funkthat.com/gitea/jmg/fbsdembdev'>FreeBSD Embedded Lab Design</url>
<url href='https://www.funkthat.com/gitea/jmg/bitelab'>Lab API code</url>
</links>

<contact>
<person>
<name>John-Mark Gurney</name>
<email>jmg@FreeBSD.org</email>
</person>
</contact>

<body><p>The Embedded Lab Project's goal is to make SBCs and other devices more
accessible to developers.  Despite SBCs often being inexpensive, it is
not inexpensive to maintain them, in terms of the cost of time to keep
them up to date, infrastructure to support them, etc.
</p>
<p>The goal of this project is to support and enhance the existing CI work
but also make it easier for developers to test their code and changes
on one, or many different boards.
</p>
<p>Once the work is [mostly] complete, I will host a lab that will be freely
available to everyone who has a FreeBSD.org account.  Information about
this will be sent once it is closer to launch.
</p>
<p>The core part of the architecture is each time a board is reserved via
the API, a new jail is created which contains the serial console tty,
an interface for internet access, and an interface that is connected
to the board's ethernet port (assuming it has one).  This allows a
clean system for each run, and allows complete control over the network
interfaces to support netbooting and other development.  The jail will
have a basic set of FreeBSD packages installed that matches the board.
</p>
<p>Part of the API will also allow power cycling the board to aid in
debugging.  This part is relatively extensible, so adding additional
modules to provide additional support should not be difficult.
</p>
<p>The API includes support for running interactive commands in the jail.
This will make it easy to script control of the environment, such as
directly running an expect script against the serial console, or even
just running a script in the jail.
</p>
<p>The work is progressing well, and currently a single board, a Pine64
A64-LTS, is integrated and working.  Board reserves and releases are
working, along with the ability to run commands in the jail via the API.
Power control is functional, and is currently using a PoE smart switch
to control power.
</p>
<p>Work has stalled on being able to use the <a href='https://wiki.tizen.org/SDWire'>SDWire</a>
with an environment due to power issues.  USB is not made for power
isolation, which is causing issues w/ power control.  The existing
board, the A64-lTS, is using a USB serial console adapter that is
opto-isolated, ensuring that there is no problems w/ power control.  But
there I have not found a solution for high speed USB.  I believe that
cutting the VBUS (power) line of a USB cable would allow fine grain
power control, but tests have not been conducted yet.
</p>
<p>Sponsor: The FreeBSD Foundation
</p></body></project>
<project cat='third'>
<title>FreshPorts</title>

<links>
<url href='http://freshports.org/'>FreshPorts</url>
<url href='http://news.freshports.org/'>FreshPorts blog</url>
</links>

<contact>
<person>
<name>Dan Langille</name>
<email>dan@langille.org</email>
</person>
</contact>

<body>
<p>FreshPorts, and its sister site, FreshSource, have reported
upon FreeBSD commits for 20 years. They cover all commits,
not just ports.
</p>
<p>FreshPorts tracks the commits and extracts data from the
port Makefiles to create a database of information useful
to both port developers and port users.
</p>
<p>For example, <a href='https://www.freshports.org/security/acme.sh/'>https://www.freshports.org/security/acme.sh/</a>
shows the history of this port, back to its creation in May 2017.
</p>
<h3>git</h3>

<p>The work to become git-ready is mostly complete. Both src and doc commits are
flowing into <a href='https://devgit.freshports.org'>devgit.freshports.org</a>. Some
work is required on various issues, but nothing that stops the flow of
commits into the database.
</p>
<h3>Help wanted</h3>

<p>Amazon have donated enough to try FreshPorts on AWS. I need help with the
following:
</p>
<ul>
<li><p>getting IPv6 working
</p></li>
<li><p>working with <a href='https://aws.amazon.com/rds/'>RDS</a>
</p>
</li></ul>
If you can help with this, please contact me. Thank you.

<p>Thank you
</p>
</body></project>
<project cat='third'>
<title>helloSystem</title>

<links>
<url href='https://hellosystem.github.io/docs/'>Documentation</url>
</links>

<contact>
<person>
<name>Simon Peter</name>
<email>probono@puredarwin.org</email>
</person>
</contact>

<body><p>Contact: <code>#helloSystem</code> on <code>irc.freenode.net</code>, mirrored to <a href='https://matrix.to/#/%23helloSystem:matrix.org?via=matrix.org'><code>#helloSystem:matrix.org</code> on Matrix</a>
</p>
<p>helloSystem is FreeBSD preconfigured as a desktop operating system
with a focus on simplicity, elegance, and usability.
Its design follows the “Less, but better” philosophy.
It is intended as a system for “mere mortals”, welcoming to switchers
from a world in which a global menu bar exists, the Command key is used
rather than Control, and applications are contained in .app bundles.
</p>
<p>helloSystem grew out of frustration with <a href='https://medium.com/@probonopd/make-it-simple-linux-desktop-usability-part-1-5fa0fb369b42'>usability shortcomings</a> of existing open source
desktop environments. FreeBSD was chosen as the base because it offers
one consistent base system rather than a <a href='https://media.ccc.de/v/ASG2018-174-2018_desktop_linux_platform_issues'>fragmented landscape of distributions lacking a common platform</a>.
</p>
<p>helloSystem aims at providing a "it just works" out-of-the-box user experience
in which a non-technical user can just use the system without ever opening
the terminal, without having to configure anything, and without ever seeing
white text on a black background scroll by during system boot. Technologies embraced
include DNS-SD/Zeroconf (also known as Bonjour), IPP Everywhere (also known as AirPrint),
eSCL (also known as AirScan), etc.
</p>
<p>Prerelease installable Live ISO images are available.
</p>
<p><a href='https://github.com/helloSystem/hello/blob/master/CONTRIBUTING.md'>Help is needed in a number of areas</a>, especially:
</p>
<ul>
<li><p>FreeBSD/kernel: allowing to put the system into a read-only disk image with a writable overlay, e.g., using unionfs
</p></li>
<li><p>Qt, Python: writing various easy-to use frontends for FreeBSD/OpenZFS functionality, e.g., Disk Utility.app
</p></li>
<li><p>Testing and bugfixing
</p></li></ul>
</body></project>
<project cat='third'>
<title>K8S-bhyve</title>

<links>
<url href='https://k8s-bhyve.convectix.com'>K8S-bhyve</url>
<url href='https://github.com/k8s-bhyve'>K8S-bhyve</url>
<url href='https://kubernetes.io/'>Kubernetes</url>
</links>

<contact>
<person>
<name>Kirill Ponomarev</name>
<email>krion@FreeBSD.org</email>
</person>
<person>
<name>Oleg Ginzburg</name>
<email>olevole@olevole.ru</email>
</person>
</contact>

<body><p>K8S-bhyve is opensource project concentrating primarily on deploying and use
of kubernetes on FreeBSD/bhyve in a more agile and more comfortable manner.
We are going to provide distributed multi-DC environment or just stand-alone
clusters with native PV/PVC support.
</p>
<p>For 2020Q4 we made and published a k8s-bhyve image which
you might install with <a href='https://k8s-bhyve.convectix.com/kbhyve-latest.iso'>ISO/memstick</a>,
as well as with <a href='http://k8s.bsdstore.ru/auto'>bsdinstall</a>.
</p></body></project>
<project cat='third'>
<title>Puppet</title>

<links>
<url href='https://puppet.com/docs/puppet/latest/puppet_index.html'>Puppet</url>
<url href='https://puppetcommunity.slack.com/messages/C6CK0UGB1/'>Puppet's FreeBSD slack channel</url>
<url href='https://puppet.com/docs/bolt/latest/bolt.html'>Bolt</url>
<url href='https://choria.io/'>Choria</url>
</links>

<contact>
<person>
<name>Puppet Team</name>
<email>puppet@FreeBSD.org</email>
</person>
</contact>

<body><p>Since our last status report a few months ago, the FreeBSD ports tree
has seen the addition of the Choria (sysutils/choria) orchestration
tool, and the Puppet Platform 7 with the Puppet Agent (sysutils/puppet7),
Puppet Server (sysutils/puppetserver7) and PuppetDB
(databases/puppetdb7).
</p>
<p>Older versions of Puppet (5 and 6) are still in the ports tree, allowing
a smooth transition, but please note that Puppet 5 will reach EOL soon,
and as it is not compatible with the recent ecosystem provided by
FreeBSD (i.e. it is not compatible with the latest version of Ruby and
depends on old FreeBSD primitives not available anymore), it is
recommended to update at least to Puppet 6 as soon as possible.
</p>
<p>Ports depending on Puppet (e.g. sysutils/rubygem-bolt) have been updated
to add options allowing to choose which version of Puppet to depend on.
For now, the default is Puppet 6, but we plan to switch the default to
Puppet 7 in a few weeks, probably when Puppet 5 will have reached EOL.
</p></body></project>
<project cat='misc'>
<title>Prometheus NFS Exporter</title>

<links>
https://github.com/Axcient/freebsd-nfs-exporter
</links>

<contact>
<person>
<name>Alan Somers</name>
<email>asomers@FreeBSD.org</email>
</person>
</contact>

<body><p>FreeBSD's nfsstat(8) utility provides a wealth of statistics, but I wanted to
monitor them with Prometheus.  Screen-scraping the --libxo output would've been
possible, but some of the stats are preprocessed in a way that interferes with
my Prometheus processing.  So I wrote a separate utility that publishes the raw
stats provided by the kernel.  Along the way I found and fixed a few bugs in
nfsstat, too.  If anybody is interested, I can add a port for it.
</p>
<p>Sponsor: Axcient<br />
</p></body></project>
  <category>
    <name>team</name>

    <description>&os; Team Reports</description>

    <p>Entries from the various official and semi-official teams,
      as found in the <a href="&enbase;/administration.html">Administration
	Page</a>.</p>
  </category>

  <category>
    <name>proj</name>

    <description>Projects</description>

    <p>Projects that span multiple categories, from the kernel and userspace
      to the Ports Collection or external projects.</p>
  </category>

  <category>
    <name>kern</name>

    <description>Kernel</description>

    <p>Updates to kernel subsystems/features, driver support,
      filesystems, and more.</p>
  </category>

  <category>
    <name>arch</name>

    <description>Architectures</description>

    <p>Updating platform-specific features and bringing in support
      for new hardware platforms.</p>.
  </category>

  <category>
    <name>bin</name>

    <description>Userland Programs</description>

    <p>Changes affecting the base system and programs in it.</p>
  </category>

  <category>
    <name>ports</name>

    <description>Ports</description>

    <p>Changes affecting the Ports Collection, whether sweeping
      changes that touch most of the tree, or individual ports
      themselves.</p>
  </category>

  <category>
    <name>doc</name>

    <description>Documentation</description>

    <p>Noteworthy changes in the documentation tree, in manpages, or in
      external books/documents.</p>
  </category>

  <category>
    <name>misc</name>

    <description>Miscellaneous</description>

    <p>Objects that defy categorization.</p>
  </category>

  <category>
    <name>third</name>

    <description>Third-Party Projects</description>

    <p>Many projects build upon &os; or incorporate components of
      &os; into their project.  As these projects may be of interest
      to the broader &os; community, we sometimes include brief
      updates submitted by these projects in our quarterly report.
      The &os; project makes no representation as to the accuracy or
      veracity of any claims in these submissions.</p>
  </category>

</report>