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
|
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE report PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for Status Report//EN"
"http://www.FreeBSD.org/XML/www/share/sgml/statusreport.dtd">
<!-- $FreeBSD: www/en/news/status/report-mar-2004-apr-2004.xml,v 1.3 2004/06/04 07:09:22 ale Exp $ -->
<report>
<date>
<month>March-April</month>
<year>2004</year>
</date>
<section>
<title>Introduction</title>
<p>2004 continues on with wonderful progress. Work continues on locking
down the network stack, ACPI made more great strides, an ARM port
appeared in the tree, and the FreeBSD 4.10 release cycle wrapped up.
Once 4.10 is released, the next big focus will be FreeBSD 5.3. We
expect this is be the start of the 5-STABLE branch, meaning that not
only will it be stable for production use, it will also be largely
feature complete and stable from an internal API standpoint. We expect
to release 5.3 in mid-summer, and we encourage everyone to download the
latest snapshots from <url href="ftp://snapshots.jp.FreeBSD.org"/>
for a preview.</p>
<p>Thanks,</p>
<p>Scott Long</p>
</section>
<project>
<title>OpenOffice.org porting status</title>
<contact>
<person>
<name>
<given>NAKATA</given>
<common>Maho</common>
</name>
<email>maho@FreeBSD.org</email>
</person>
</contact>
<body>
<p>After almost three years efforts for porting OpenOffice.org 1.0.x and
1.1.0 for FreeBSD by Martin Blapp (mbr@FreeBSD.org) and other
contributors, There are four version of OpenOffice.org (OOo) in ports
tree. 1.1.1: stable version, 1.1.2: next stable, 2.0: developer and
1.0.3: legacy.
</p>
<p>Stable version 1.1.1 in /usr/ports/editors/openoffice-1.1/
builds/installs/works fine for 5.2.1-RELEASE. Packages for
5.2.1-RELEASE, 26 localized versions and 4.10-PRELEASE only English
version, are available at
http://oootranslation.services.openoffice.org/pub/OpenOffice.org/ooomisc/
(note: source of OOo 1.1.1.RC3 is identical OOo 1.1.1)</p>
<p>Patches needed to build are currently 18 for 1.1.1, and 161 for 1.0.3
the number of patches are greatly reduced.</p>
<p>OOo 1.1.2, the next stable version in
/usr/ports/editors/openoffice-1.1-devel is also builds/installs/works
fine for 5.2.1-RELEASE. We are planning to upgrade this port as soon
as 1.1.2 will be released.</p>
<p>Next major release, 2.0 (planned to be released at January 2005
according to
http://development.openoffice.org/releases/OpenOffice_org_trunk.html),
/usr/ports/editors/openoffice-2.0-devel, now compiles for
5.2.1-RELEASE but have big problem that prohibits to remove BROKEN.</p>
<p>Legacy version, OOo 1.0.3: /usr/ports/editors/openoffice-1.0/ I'm not
interested in this port. We hope someone else will maintain this.</p>
<p>For builds, my main environment is 5.2.1-RELEASE, and I have no access
to 4-series, so several build problems had been reported for 5-current
and 4-stable, however, they now seems to be fixed. Please make sure
your Java and/or kernel are up-to-date.</p>
<p>For version 1.1.1, yet we have serious reproducible core dumps, this
means OOo cannot pass the Quality Assurance protocol of OpenOffice.org
(http://qa.openoffice.org), so we cannot release OOo as quality
assured package. It seems to be FreeBSD's userland bug, since some
reports show that there are no problem for 4-stable but we still
searchingthe reason.</p>
<p>Note that developers should sign JCA (Joint Copyright Assignment)
before submitting patches via PR or e-mail, otherwise patches won't be
integrated to OOo's source tree. We seriously need more developers,
testers and builders.</p>
</body>
</project>
<project>
<title>Network interface naming changes</title>
<contact>
<person>
<name>
<given>Brooks</given>
<common>Davis</common>
</name>
<email>brooks@FreeBSD.org</email>
</person>
</contact>
<body>
<p>An enhanced network interface cloning API has been created. It
allows interfaces to support more complex names than the current
name# style. This functionality has been used to enable
interesting cloners like auto-configuring vlan interfaces. Other
features include locking of cloner structures and the ability of
drivers to reject destroy requests. A patch has been posted to
the freebsd-net mailing list for review and will be committed in
early May. This work is taking place in the perforce repository
under: //depot/user/brooks/xname/...</p>
</body>
</project>
<project>
<title>FreeBSD Dutch Documentation Project</title>
<contact>
<person>
<name>
<given>Remko</given>
<common>Lodder</common>
</name>
<email>remko@elvandar.org</email>
</person>
</contact>
<links>
<url href="http://www.evilcoder.org/index.cgi?i=nav&t=freebsd">Status and download of the documentation (not yet complete)</url>
</links>
<body>
<p>The FreeBSD Dutch Documentation Project is a ongoing project in
translating the handbook and other documentation to the Dutch
language. Currently we have a small team of individuals who
translate, check other's work, and publish them on the internet.
You can view the current status on the webpage (listed above).
Still we can use more people helping out, since we have a long
way to go. Every hand that wants to help, contact me, and i will
provide you details on how we work etc. Currently the project has
translated the handbook pages of: The X Windows System, and
Configuration and Tuning, they only need to be checked before
publishing.</p>
</body>
</project>
<project>
<title>ACPI</title>
<contact>
<person>
<name>
<given>Nate</given>
<common>Lawson</common>
</name>
<email>njl@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.root.org/~nate/freebsd/">ACPI TODO</url>
<url href="http://lists.freebsd.org/mailman/listinfo/freebsd-acpi">
ACPI Mailing List</url>
</links>
<body>
<p>Much of the ACPI project is waiting for architectural changes to be
completed. For instance, the cpufreq driver requires newbus
attachments for CPUs. Support code for this should be committed
at the time of publication. Other architectural changes needed
include rman support for memory/port resources and a generic hotkey
and extras driver. Important work in other areas of the kernel
including PCI powerstate support and APIC support have been
invaluable in improving ACPI on modern platforms. Thanks go to
Warner Losh and John Baldwin for this work.</p>
<p>Code which is mostly completed and will go in once the groundwork
is finished includes the cpufreq framework, an ACPI floppy controller
driver, and full support for dynamic Cx states.</p>
<p>ACPI-CA was updated to 20040402 in early April. This has some GPE
issues that persist in 20040427 that will hopefully be resolved by
the date of publication.</p>
<p>I'd like to welcome Mark Santcroos (marks@) to the FreeBSD team.
He has helped in the past with debugging ACPI issues.
If any developers are interested in assisting with ACPI, please
see the ACPI TODO and send us an email.</p>
</body>
</project>
<project>
<title>Verify source reachability option for ipfw2</title>
<contact>
<person>
<name>
<given>Andre</given>
<common>Oppermann</common>
</name>
<email>andre@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.freebsd.org/news/status/report-jan-2004-feb-2004.html#Verify-source-reachability-option-for-ipfw2"/>
<url href="http://www.freebsd.org/cgi/man.cgi?query=ipfw&apropos=0&sektion=0&manpath=FreeBSD+5.2-current&format=html"/>
</links>
<body>
<p>The verify source reachability option for ipfw2 has been committed
on 23. April 2004 to FreeBSD-CURRENT. For more information see the
links above.</p>
</body>
</project>
<project>
<title>Convert ipfw2 to use PFIL_HOOKS mechanism</title>
<contact>
<person>
<name>
<given>Andre</given>
<common>Oppermann</common>
</name>
<email>andre@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.nrg4u.com/freebsd/ipfw-pfilhooks-and-more-20040510.diff"/>
</links>
<body>
<p>ipfw2 is built directly into ip_input() and ip_output() and it makes
these functions more complicated. For some time now we have the
generic packet filter mechanism PFIL_HOOKS which are used by IPFILTER
and the new OpenBSD PF firewall packages to hook themselves into the
IP input and output path.</p>
<p>This patch makes ipfw2 fully self contained and callable through the
PFIL_HOOKS. This is still work in progress and DUMMYNET and IPDIVERT
plus Layer2 firewall are not yet fully functional again but normal
firewalling with it works just fine.</p>
<p>The patch contains some more cleanups of ip_input() and ip_output()
that is work in progress too.</p>
</body>
</project>
<project>
<title>Move ARP out of routing table</title>
<contact>
<person>
<name>
<given>Luigi</given>
<common>Rizzo</common>
</name>
<email>luigi@FreeBSD.org</email>
</person>
<person>
<name>
<given>Andre</given>
<common>Oppermann</common>
</name>
<email>andre@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://lists.freebsd.org/pipermail/freebsd-current/2004-April/026380.html"/>
</links>
<body>
<p>The ARP IP address to MAC address mapping does not belong into
the routing table (FIB) as it is currently done. This will move
it to its own hash based structure which will be instantiated per
each 802.1 broadcast domain. With this change it is possible to
have more than one interface in the same IP subnet and layer 2
broadcast domain. The ARP handling and the routing table will be
quite a bit simplified afterwards. As an additional benefit full
MAC address based accounting will be provided.</p>
<p>Luigi has become the driver of this project and posted a first
implementation for comments on 25. April 2004 (see link).</p>
</body>
</project>
<project>
<title>Automatic sizing of TCP send buffers</title>
<contact>
<person>
<name>
<given>Andre</given>
<common>Oppermann</common>
</name>
<email>andre@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.freebsd.org/news/status/report-jan-2004-feb-2004.html#Automatic-sizing-of-TCP-send-buffers"/>
</links>
<body>
<p>The current TCP send and receive buffers are static and set to a
conservative value to preserve kernel memory. This is sub-optimal
for connections with a high bandwidth*delay product because the
size of the TCP send buffer determines how big the send window can
get. For high bandwidth trans-continental links this seriously
limits the maximum transfer speed per TCP connection. A moredetailed
description from the last status report can be found with the link
above.</p>
<p>Work on this project has been stalled due to some other network stack
projects with higher precedence (ipfw2 to pfil_hooks and
ip_input/ip_output cleanups).</p>
</body>
</project>
<project>
<title>libarchive/bsdtar</title>
<contact>
<person>
<name>
<given>Tim</given>
<common>Kientzle</common>
</name>
<email>kientzle@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://people.freebsd.org/~kientzle/"/>
</links>
<body>
<p>Both bsdtar and libarchive are now part of -CURRENT.
A few minor problems have been reported and addressed,
including performance issues with many hard-links, and
options required by certain packages.
For now, the "tar" command is still an alias for "gtar."
Those who would like to use bsdtar as the default system tar
can define WITH_BSDTAR to make "tar" be an alias for
"bsdtar."</p>
<p>My current plan is to make bsdtar be the default in -CURRENT in
about another month, probably after the 5-STABLE split, and remove
gtar from -CURRENT sometime later. It's still open if and when
this switch will occur in 5-STABLE. On the one hand, I see
potential problems if 5-STABLE and 6-CURRENT have different tar
commands; on the other hand, switching could be disruptive for
some users.</p>
</body>
</project>
<project>
<title>GEOM Gate</title>
<contact>
<person>
<name>
<given>Pawel Jakub</given>
<common>Dawidek</common>
</name>
<email>pjd@FreeBSD.org</email>
</person>
</contact>
<body>
<p>GEOM Gate class is now committed as well as ggatec(8), ggated(8)
and ggatel(8) utilities. It makes distribution of disk devices
through the network possible, but on the disk level (don't confuse
it with NFS, which provides exporting data on the file system
level).</p>
</body>
</project>
<project>
<title>Improved Multibyte/Wide Character Support</title>
<contact>
<person>
<name>
<given>Tim</given>
<common>Robbins</common>
</name>
<email>tjr@FreeBSD.org</email>
</person>
</contact>
<body>
<p>New locales: Unicode UTF-8 locales have been added to the base system.
All of the locales previously supported by FreeBSD now have a
corresponding UTF-8 version, along with one or two new ones --
53 in all.</p>
<p>Library changes: The restartable conversion functions (mbrtowc(),
wcrtomb(), etc.) in the C library have been updated to handle partial
characters in the way prescribed by the C99 standard.
The <wctype.h> functions have been optimized for handling
large, fragmented character sets like Unicode and GB18030.
Documentation has been improved.</p>
<p>Utilities: The ls utility has been modified to work with wide
characters internally when determining whether a character in a
filename is printable, and how many column positions it takes on
the screen. Character handling in the wc utility has been made
more robust. Other text-processing utilities (expand, fold, unexpand,
uniq) have been modified, but these changes have not been committed
until the performance impact can be evaluated. Work on a POSIX-style
localedef utility has started, with the aim to have it replace
the current mklocale and colldef utilities in FreeBSD 6.
(It is currently on the back-burner awaiting a response to a POSIX
defect report.)</p>
<p>Future directions: wide character handling functions need to be
optimized so that they are more competitive with the single-byte
functions when dealing with 8-bit character sets. Utilities need to
be modified to handle multibyte characters, but with a careful eye
on performance. Localedef needs to be finished.</p>
</body>
</project>
<project>
<title>ATA project Status Report</title>
<contact>
<person>
<name>
<given>Søren</given>
<common>Schmidt</common>
</name>
<email>sos@FreeBSD.org</email>
</person>
</contact>
<body>
There is finally support (except for RAID5) for the Promise SX4/SX4000
line of controllers. The support is rudimentary still, and doesn't
really make any good use of the cache/sequencer HW yet. The Silicon
Image 3114 support has been completed. Lots of bug fixes and cleanups.
Future work now concentrates on new controller chips (Marvell SATA
chips probably the most prominent) and getting the SATA support
finished so that hotswap etc works with SATA HW as well. Also ATA RAID
is about to get rewritten to take advantage of the features that the
ATA subsystem now offers, including support for the HW on
Promise/Marvell and the like controllers. A number of new RAID metadata
<p>formats (Intel, AMI) is also in the works.</p>
</body>
</project>
<project>
<title>Porting OpenBSD's packet filter</title>
<contact>
<person>
<name>
<given>Max</given>
<common>Laier</common>
</name>
<email>mlaier@FreeBSD.org</email>
</person>
<person>
<name>
<given>Daniel</given>
<common>Hartmeier</common>
</name>
<email>dhartmei@FreeBSD.org</email>
</person>
<person>
<name>
<given>Pyun</given>
<common>YongHyeon</common>
</name>
<email>yongari@kt-is.co.kr</email>
</person>
</contact>
<links>
<url href="http://pf4freebsd.love2party.net/"/>
<url href="http://www.benzedrine.cx/pf.html"/>
<url href="http://openbsd.org/faq/pf/index.html"/>
<url href="http://www.rofug.ro/projects/freebsd-altq/"/>
</links>
<body>
<p>The two months after the import was done were actually rather quiet.
We imported a couple of minor fixes from the OpenBSD stable branch.
The import of tcpdump 3.8.3 and libpcap 0.8.3 done by Bruce M.Simpson
in late March finally put us into the position to build a working
pflogd(8) and provide rc.d linkage for it. Tcpdump now understandsthe
pflog(4) pseudo-NIC packet format and can be used to read the
log-files.</p>
<p>There has also been work behind the scenes to prepare an import of
the OpenBSD 3.5 sources. The patches are quite stable already andwill
be posted shortly. Altq is in the making as well and going alongquite
well based on the great work from rofug.ro, but as it needs
modifications to every network driver which have to be tested
thoroughly it needs more time.</p>
</body>
</project>
<project>
<title>The FreeBSD Simplified Chinese Project</title>
<contact>
<person>
<name>
<given>Xin</given>
<common>LI</common>
</name>
<email>delphij@frontfree.net</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org.cn">The FreeBSD Simplified
Chinese Project (In Simplified Chinese)</url>
<url href="http://www.FreeBSD.org.cn/snap/doc/zh_CN.GB2312/books/handbook/">
Translated Handbook Snapshot</url>
<url href="http://www.freebsd.org.cn/cndocs/translations.html">
Translation status</url>
<url href="http://www.FreeBSD.org.cn/snap/zh_CN/">Translated
Website Snapshot</url>
</links>
<body>
<p>We have finished about 75% of the Handbook translation work.
In the last two months we primarily worked on bringing the
handbook chapters more up to date. To make the translation
more high quality we are also doing some revision on it.</p>
<p>We are still looking for manpower on SGML'ifying the FAQ
translation which has been done last year by several volunteers.</p>
</body>
</project>
<project>
<title>Cronyx Tau-ISA driver</title>
<contact>
<person>
<name>
<given>Roman</given>
<common>Kurakin</common>
</name>
<email>rik@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.cronyx.ru/hardware/wan.html">Cronyx WAN Adapters.</url>
</links>
<body>
<p>ctau(4) driver for Cronyx Tau-ISA was added. Cronyx Tau-ISA is family
of synchronous WAN adapters with various set of interfaces such as
V.35, RS-232, RS-530(449), E1 (both framed and unframed). This is a
second family of Cronyx adapters that is supported by FreeBSD now. The
first one was Cronyx Sigma-ISA, cx(4).</p>
<p>Cronyx Tau-PCI family will become a third one. The peculiarity of this
driver that it contains private code. This code is distributed as
obfuscated source code with usual open source license agreement.Since
code is protected by obfuscation it is satisfy needs of commerce. On
the other hand it still stays a source code and thus it becomes closer
to open source projects. I hope this form of private code distribution
will become a real alternative to object form.</p>
</body>
</project>
<project>
<title>Sync protocols (Netgraph and SPPP)</title>
<contact>
<person>
<name>
<given>Roman</given>
<common>Kurakin</common>
</name>
<email>rik@FreeBSD.org</email>
</person>
</contact>
<body>
<p>As part of my work on synchronous protocol stack a ng_sppp driver was
added to the system. This driver allows to use sppp as a Netgraph
node. Now I plan to update sppp driver as much as possible to make it
in sync with Cronyxs one (PPP part). Also I work on FRF.12 support in
FreeBSD (now I have FRF.12 support for Netgraph and SPPP (and for
Cronyx linux fr driver) but only End-to-End). I plan to test it by my
self within a week and after that I plan to make full support of
FRF.12.</p>
<p>If you want to get current version and test it, please feel free to
contact me.</p>
</body>
</project>
<project>
<title>FreeBSD threading support</title>
<contact>
<person>
<name>
<given>David</given>
<common>Xu</common>
</name>
<email>davidxu@FreeBSD.org</email>
</person>
<person>
<name>
<given>Doug</given>
<common>Rabson</common>
</name>
<email>dfr@FreeBSD.org</email>
</person>
<person>
<name>
<given>Julian</given>
<common>Elischer</common>
</name>
<email>julian@FreeBSD.org</email>
</person>
<person>
<name>
<given>Marcel</given>
<common>Moolinar</common>
</name>
<email>marcel@FreeBSD.org</email>
</person>
<person>
<name>
<given>Dan</given>
<common>Eischen</common>
</name>
<email>deischen@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://people.freebsd.org/~marcel/tls.html">basic data on
TLS</url>
<url href="http://www.freebsd.org/kse/index.html">basic threads
page</url>
</links>
<body>
<p>
Threading developers have been active behind the scenes
though not much has been visible. Real Life(TM) has been
hard on us as a group however.</p>
<p> Marcel and Davidxu have both (individually)
been looking at the support
for debugging threaded programs. David has a set of
patches that allow gdb to correctly handle KSE programs and
patches are being considered for libthr based processes.
Marcel added a Thread ID to allow debugging code to unambiguously
specify a thread to debug. He has also been looking at corefile
support. Both sets of patches are preliminary.</p>
<p>Dan Eischen continues to support people migrating to
libpthreads and it seems to be going well.</p>
<p>Doug Rabson has done his usual miracle work and produced
a set of preliminary patches to implement TLS (Thread
Local Storage) for the i386 platform.</p>
<p>Julian Elischer is investigating some refactoring of the kernel
support code.</p>
<p>Platforms:</p>
<p>i386, amd64, ia64 libpthread works.</p>
<p>alpha, sparc64 not implemented.</p>
</body>
</project>
<project>
<title>Binary security updates for FreeBSD</title>
<contact>
<person>
<name>
<given>Colin</given>
<common>Percival</common>
</name>
<email>cperciva@daemonology.net</email>
</person>
</contact>
<links>
<url href="http://www.daemonology.net/freebsd-update/"/>
</links>
<body>
<p>Having recently passed its first birthday, FreeBSD Update is
now being used on about 170 machines every day; on a typical
day, around 60 machines will download updates (the others being
already up to date). To date, over 157000 files have been
updated on over 4200 machines.</p>
</body>
</project>
<project>
<title>PCI Powerstates and Resource</title>
<contact>
<person>
<name>
<given>Warner</given>
<common>Losh</common>
</name>
<email>imp@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Lazy allocation of pci resources has been merged into the main
tree. These changes allow FreeBSD to run on computers where PnP
OS is set to true. In addition, the saving and restoring of the
resources across suspend/resume has helped some devices come
back from suspend.</p>
<p>Future work will focus on bus numbering.</p>
</body>
</project>
<project>
<title>Book: The Design and Implementation of the FreeBSD Operating System</title>
<contact>
<person>
<name>
<given>Kirk</given>
<common>McKusick</common>
</name>
<email>mckusick@FreeBSD.org</email>
</person>
<person>
<name>
<given>George</given>
<common>Neville-Neil</common>
</name>
<email>gnn@neville-neil.com</email>
</person>
</contact>
<links>
<url href="http://www.mckusick.com/FreeBSDbook.html"/>
</links>
<body>
<p>The new Book "The Design and Implementation of the FreeBSD Operating
System" is the successor of the legendary "The Design and
Implementation of 4.4BSD" book which has become the de-facto standard
for teaching of Operating System internals in universities
world-wide.</p>
<p>This new and completely reworked edition is based on FreeBSD 5.2 and
the upcoming FreeBSD 5.3 releases and contains in-details looks into
all areas (from virtual memory management to interprocess
communication and network stack) of the operating system on 700
pages.</p>
<p>It is now in final production by Addison-Wesley and will be available
in early August 2004. The ISBN is 0-201-70245-2.</p>
</body>
</project>
<project>
<title>Status Report </title>
<contact>
<person>
<name>
<given>Roland</given>
<common>van Laar</common>
</name>
<email>the_mip_rvl@myrealbox.com</email>
</person>
</contact>
<links>
<url href="http://wleiden.webweaving.org:8080/svn/node-config/other/enh-sec-patch/README"/>
<url href="http://bsd.slashdot.org/article.pl?amp;sid=03/12/27/2035245&mode=thread&tid=122&tid=126&tid=137&tid=172&tid=185&tid=190&tid=193"/>
</links>
<body>
<p>This patch if for if_wi current. It enables you to disable the ssid
broadcasting and it also allows you to disable clients connecting
with a blank ssid.</p>
</body>
</project>
<project>
<title>SMPng Status Report</title>
<contact>
<person>
<name>
<given>John</given>
<common>Baldwin</common>
</name>
<email>jhb@FreeBSD.org</email>
</person>
<person>
<email>smp@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/smp/"/>
</links>
<body>
<p>Several folks continue to work on the locking the network stack
as noted elsewhere in this report. Outside of the network stack,
the following items were worked on during the March and April time
frame. Giant was pushed down in the fork, exit, and wait system
calls as far as possible. Alan Cox (alc@) continues to lock the
VM subsystem and push down Giant where appropriate. A few system
calls and callouts were marked MP safe as well.</p>
<p>A few changes were made to the interrupt thread infrastructure.
Interrupt thread preemption was finally enabled on the Alpha
architecture with the help of the recently added support to the
scheduler for pinning threads to a specific CPU. An optimization
to reduce context switches during heavy interrupt load was added
as well as rudimentary interrupt storm protection.</p>
</body>
</project>
<project>
<title>FreeBSD/arm</title>
<contact>
<person>
<name>
<given>Olivier</given>
<common>Houchard</common>
</name>
<email>cognet@FreeBSD.org</email>
</person>
</contact>
<body>
<p>FreeBSD/arm is now in the FreeBSD CVS tree. Dynamic libraries now work,
and NO_CXX=true NO_RESCUE=true buildworld works too (with patches for
toolchain that will live outside the tree for now). Now the focus
should be on xscale support.</p>
</body>
</project>
<project>
<title>CAM lockdown and threading</title>
<contact>
<person>
<name>
<given>Scott</given>
<common>Long</common>
</name>
<email>scottl@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Work has begun on locking down the CAM subsystem. The project is
divided into several steps:
</p>
<ul>
<li>Separation of the SCSI probe peripheral from cam_xpt.c to
scsi_probe.c</li>
<li>Threading of the device probe sequence.</li>
<li>Locking and reference counting the peripheral drivers.</li>
<li>Locking the XPT and device queues.</li>
<li>Locking one or more SIMs and devising a way for non-locked drivers
to function.</li>
</ul>
<p>While the immediate goal of this work is to lock CAM, it also points
us in the direction of separating out the SCSI-specific knowledgefrom
the core. This will allow other transports to be written, such as
SAS, iSCSI, and ATA.</p>
<p>Progress is being tracked in the FreeBSD Perforce server in the
camlock branch. I will make public patches available once it has
progressed far enough for reasonable testing. So far, the first two
items are being worked on.</p>
</body>
</project>
<project>
<title>Network Stack Locking</title>
<contact>
<person>
<name>
<given>Robert</given>
<common>Watson</common>
</name>
<email>rwatson@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.freebsd.org/smp/">SMPng Web Page</url>
<url href="http://www.watson.org/~robert/freebsd/netperf/">Robert's
Network Stack Locking Page</url>
</links>
<body>
<p>This project is aimed at converting the FreeBSD network stack from
running under the single Giant kernel lock to permitting it to run
in a fully parallel manner on multiple CPUs (i.e., a fully threaded
network stack). This will improve performance/latency through
reentrancy and preemption on single-processor machines, and also on
multi-processor machines by permitting real parallelism in the
processing of network traffic. As of FreeBSD 5.2, it was possible to
run low level network functions, as well as the IP filtering and
forwarding plane, without the Giant lock, as well as "process to
completion" in the interrupt handler.</p>
<p>Work continues to improve the maturity and completeness of the
locking (and performance) of the network stack for 5.3. The network
stack development branch has been updated to the latest CVS HEAD,
as well as the following and more:</p>
<ul>
<li>Review of socket flag and socket buffer flag locking;
so_state broken out into multiple fields covered by different
locks to avoid lock orders in frobbing the so_state field.
Work in progress.</li>
<li>WITNESS now includes hard ordering for many network locks to
improve lock order debugging process.</li>
<li>MAC Framework modified to use pcbs instead of sockets in a
great many situations to avoid socket locking in network layer,
especially when generating new mbufs.</li>
<li>New annotations relating to socket and interface locking.</li>
<li>Began NetGraph review and corrected NetGraph socket locking
problems.</li>
<li>sendfile() locking appears now to be fixed, albeit holding
Giant more than strictly necessary.</li>
<li>if_ppp global variable locking performed and merged.</li>
<li>A variety of race conditions and bugs in soreceive() locking
fixed, including existing race conditions triggered only rarely
in -HEAD and -STABLE that triggered easily with SMP and Giant-free
operation.</li>
<li>Locking of socket buffer and socket fields from fifofs.
Proposed patch to correct lock order problem between vnode
interlock and socket buffer lock order problems. fifofs
interactions with UNIX domain sockets cleaned up.</li>
<li>Research into KQueue issues. Feedback to KQueue locking
patch authors.</li>
<li>netatalk AARP locked down, MPSAFE, and merged to CVS.</li>
<li>Lock order issues between socket, socket buffer, and UNIX domain
socket locks corrected. Race conditions and potential deadlocks
removed.</li>
<li>if_gif recursion cleanups, if_gif is much more MPSAFE.</li>
<li>First pass MPSAFE locking of NFS server uses an NFS server
subsystem lock to allow so_upcall() from socket layer without
Giant. This closes race conditions in the NFS server when
operating Giant free. Second pass for data based locking is
also in testing.</li>
<li>if_sl.c (SLIP) fine-grained locking completed and merged to
CVS.</li>
<li>if_tun.c (tunnel) fine-grained locking completed and merged to
CVS.</li>
<li>Merge of conditional Giant locking on debug.mpsafenet to CVS;
semantics now changed so that Giant isn't just twiddled over
the forwarding path, but the entire stack. Must be used with
caution unless running with our patches. Callouts also
convered to conditional safety.</li>
<li>if_gif, if_gre global variables locked and merged to CVS.</li>
<li>netatalk DDP cleanup (break out PCB from protocol code),
largely locked down at the PCB level. Some work remains to
be done before patches can be distributed for testing, but close
to MPSAFE.</li>
<li>Began review of netipx, netinet6 code for locking requirements,
some bugs corrected.</li>
<li>Race conditions in handling of socket so_comp, so_incomp
debugged and hopefully closed through new locking of these
fields.</li>
<li>Many new locking annotations, field documentation, lock order
documentation.</li>
</ul>
<p>Netperf patches are proving to be quite stable in a broad variety
of environment, as long as non-MPSAFE chunks are avoided. Kqueue,
IPv6, and ifnet locking remain the most critical areas where
additional functionality is required. Focus is shifting from new
development to in depth testing, performance measurement, and
interactions with other subsystems.</p>
<p>This work would not be possible without contributions from the
following people (and no doubt many others):
John Baldwin, Bob Bishop, Brooks Davis, Pawel Jakub Dawidek, Matthew
Dodd, Julian Elischer, Ruslan Ermilov, John-Mark Gurney, Jeffrey Hsu,
Kris Kennaway, Roman Kurakin, Max Laier, Sam Leffler, Scott Long, Rick
Maklem, Bosko Milekic, George Neville-Neil, Andre Oppermann, Luigi
Rizzo, Jeff Roberson, Tim Robbins, Mike Silberback, Bruce Simpson,
Seigo Tanimura, Hajimu UMEMOTO, Jennifer Yang, Peter Wemm. We hope to
present these patches on arch@ within a few days, although some
elements required continued refinement (especially socket locking).</p>
</body>
</project>
<project>
<title>TrustedBSD Mandatory Access Control (MAC)</title>
<contact>
<person>
<name>
<given>Robert</given>
<common>Watson</common>
</name>
<email>rwatson@FreeBSD.org</email>
</person>
<person>
<name>
<common>TrustedBSD Discussion List</common>
</name>
<email>trustedbsd-discuss@TrustedBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.TrustedBSD.org/">TrustedBSD Project</url>
</links>
<body>
<p>The TrustedBSD Mandatory Access Control (MAC) Framework
permits the FreeBSD kernel and userspace access control
policies to be adapted at compile-time, boot-time, or
run-time. The MAC Framework provides common infrastructure
components, such as policy-agnostic labeling, making it
possible to easily development and distribute new access
control policy modules. Sample modules include Biba, MLS,
and Type Enforcement, as well as a variety of system
hardening policies.</p>
<p>The TrustedBSD MAC development branch in Perforce was
integrated to the most recent 5-CURRENT.</p>
<p>mdmfs(8) -l to create multi-label mdmfs file systems (merged).</p>
<p>Diskless boot updated to support MAC.</p>
<p>Re-arrangement of MAC Framework code to break out mac_net.c
into mac_net.c, mac_inet.c, mac_socket.c (merged).</p>
<p>libugidfw(3) grows bsde_add_rule(3) to automatically allocate
rule numbers (merged). ugidfw(8) grows 'add' to use this
(merged).</p>
<p>pseudofs(4) no longer requires MAC localizations.</p>
<p>BPF fine-grained locking now used to protect BPD descriptor
labels instead of Giant (merged).</p>
<p>Prefer inpcb's as the source of labels over sockets when
creating new mbufs throughout the network stack, reducing
socket locking issues for labels.</p>
</body>
</project>
<project>
<title>TrustedBSD Security-Enhanced BSD (SEBSD) port</title>
<contact>
<person>
<name>
<given>Robert</given>
<common>Watson</common>
</name>
<email>rwatson@FreeBSD.org</email>
</person>
<person>
<name>
<common>TrustedBSD Discussion List</common>
</name>
<email>trustedbsd-discuss@TrustedBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.TrustedBSD.org/">TrustedBSD Project</url>
</links>
<body>
<p>TrustedBSD "Security-Enhanced BSD" (SEBSD) is a port of NSA's
SELinux FLASK security architecture, Type Enforcement (TE)
policy engine and language, and sample policy to FreeBSD using
the TrustedBSD MAC Framework. SEBSD is available as a loadable
policy module for the MAC Framework, along with a set of
userspace extensions support security-extended labeling calls.
In most cases, existing MAC Framework functions provide the
necessary abstractions for SEBSD to plug in without SEBSD-specific
changes, but some extensions to the MAC Framework have been
required; these changes are developed in the SEBSD development
branch, then merged to the MAC branch as they mature, and then
to the FreeBSD development tree.</p>
<p>Unlike other MAC Framework policy modules, the SEBSD module
falls under the GPL, as it is derived from NSA's
implementation. However, the eventual goal is to support
plugging SEBSD into a base FreeBSD install without any
modifications to FreeBSD itself.</p>
<p>Integrated to latest FreeBSD CVS and MAC branch.</p>
<p>New FreeBSD code drop updated for capabilities in preference
to superuser checks.</p>
<p>Installation instructions now available!</p>
</body>
</project>
<project>
<title>TrustedBSD Audit</title>
<contact>
<person>
<name>
<given>Robert</given>
<common>Watson</common>
</name>
<email>rwatson@FreeBSD.org</email>
</person>
<person>
<name>
<common>TrustedBSD Discussion List</common>
</name>
<email>trustedbsd-discuss@TrustedBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.TrustedBSD.org/">TrustedBSD Project</url>
</links>
<body>
<p>The TrustedBSD Project is producing an implementation of CAPP
compliant Audit support for use with FreeBSD based on the Apple
Darwin implementation.</p>
<p>Experimentally integrated the XNU audit implementation from Apple's
Darwin 7.2 into Perforce.</p>
<p>Adapted audit framework to compile into FreeBSD -- required
modifying memory allocation and synchronization to use FreeBSD
SMPng primitives instead of Mach primitives.
Pushed down the Giant lock out of most of the audit code, various
other FreeBSD adaptations such as suser() API changes, using BSD
threads, td->td_ucred, etc.</p>
<p>Adapted per-thread audit data to map to FreeBSD threads</p>
<p>Cleaned up userspace/kernel API interactions, including udev_t/
dev_t inconsistencies between Darwin and FreeBSD.</p>
<p>Use vn_fullpath() instead of vn_getpath(), which is a less
complete solution we'll need to address in the future.</p>
<p>Basic kernel framework now operates on FreeBSD; praudit
tool written that can parse FreeBSD BSM and Solaris BSM.</p>
</body>
</project>
</report>
|
