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
|
<?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$ -->
<report>
<date>
<month>March-September</month>
<year>2003</year>
</date>
<section>
<title>Introduction:</title>
<p>The FreeBSD Bi-monthly status reports are back! In this edition, we
catch up on seven highly productive months and look forward to
the end of 2003.</p>
<p>As always, the FreeBSD development crew has been hard at work. Support
for the AMD64 platform quickly sprang up and is nearly complete. KSE
has improved greatly since the 5.1 release and will soon become the
default threading package in FreeBSD. Many other projects are in the
works to improve performance, enhance the user experience, and expand
FreeBSD into new areas. Take a look below at the impressive summary of
work!</p>
<p>Scott Long, Robert Watson</p>
</section>
<project>
<title>VideoBSD</title>
<contact>
<person>
<name>
<given>John-Mark</given>
<common>Gurney</common>
</name>
<email>jmg@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://people.FreeBSD.org/~jmg/videobsd.html">Documentation of
VideoBSD</url>
</links>
<body>
<p>Still in the planning stage. Working on creating an extensible
interface that is usable for both userland and kernel implementations
for device drivers. Deciding on how to interface userland implemented
device drivers with applications.</p>
</body>
</project>
<project>
<title>KSE</title>
<contact>
<person>
<name>
<given>Dan</given>
<common>Eischen</common>
</name>
<email>deischen@FreeBSD.org</email>
</person>
<person>
<name>
<given>David</given>
<common>Xu</common>
</name>
<email>davidxu@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/kse/index.html">KSE Project
Page</url>
</links>
<body>
<p>KSE seems to be working well on x86, amd64, and ia64. The
alpha userland bits are done, but a couple of functions are
unimplemented in the kernel. For sparc64, the necessary
functions are implemented in the kernel, but the userland
context switching functions need more attention.</p>
<p>Since 5.1, efficient scope system threads (no upcalls when they block)
have been implemented, and KSE based pthread library can have both POSIX
scope process threads and scope system threads. It is also possible
that KSE based pthread library can implement pthread both in 1:1 and M:N
mode, I know Dan has such Makefile file patch for libkse not yet
committed.</p>
<p>KSE program now can work under ULE scheduler, its efficient should be
improved under the new scheduler in future. BSD scheduler is still the
best scheduler for current KSE implement.</p>
</body>
</project>
<project>
<title>FreeBSD/ia64</title>
<contact>
<person>
<name>
<given>Marcel</given>
<common>Moolenaar</common>
</name>
<email>marcel@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/platforms/ia64/index.html">Project home
page.</url>
</links>
<body>
<p>Much has happened since the last bi-monthly report, which was more
than half a year ago. FreeBSD 5.0 and FreeBSD 5.1 have been released
for example. With FreeBSD 5.2 approaching quickly, we're not going
to look back too far when it comes to our achievements. There's too
much ahead of us...</p>
<p>Two milestones have been reached after FreeBSD 5.1. The first is the
ability to support both Intel and HP machines with sources in CVS.
This due to a whole new driver for serial ports, or UARTs. Unfortunately
this still implies that syscons is not configured. That's another task
for another time, but keep an eye on KGI/FreeBSD...
The second milestone is the completion of KSE support. Both M:N and
1:1 threading is functional on ia64 and the old libc_r library has been
obsoleted. Testing has shown that KSE (i.e. M:N) may well become the
default threading model. It's looking good.</p>
<p>The ABI hasn't changed after 5.1 and the expectation is that it won't
change much. This means that we can think about becoming a tier 1
platform. This also means we need gdb(1) support. Work on it has been
started but the road is bumpy and long.
Kernel stability also has improved significantly and we typically have
one kernel panic remaining: VM fault on no fault entry. This will be
addressed with the long awaited PMAP overhaul (see below).</p>
<p>Most work for FreeBSD 5.2 will be "sharpening the saw". Get those
loose ends tied. This is a slight change of plan made possible by a
slip in the release schedule. The 5.2 release is not going to be the
start of the -stable branch; it has been moved to 5.3. So, we use the
extra time to prepare the ground for 5.3.</p>
<p>The planned PMAP overhaul will probably be finished after 5.2. This
should address all known issues with SMP and fix those last panics.
As a side-effect, major performance improvements can be expected. More
news about this in the next status reports.</p>
</body>
</project>
<project>
<title>Disk I/O</title>
<contact>
<person>
<name>
<given>Poul-Henning</given>
<common>Kamp</common>
</name>
<email>phk@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The following items are in progress in the Disk I/O area:
Turn scsi_cd.c into a GEOM driver. (Patch out for review).
Turn atapi-cd.c into a GEOM driver.
Turn fd.c into a GEOM driver.
Move softupdates and snapshot processing from SPECFS to UFS/FFS.
Move userland access to device drivers out of vnodes.</p>
<p>Once these preliminaries are dealt with, scatter/gather and
mapped/unmapped support will be added to struct bio/GEOM.</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>FreeBSD Update is a system for tracking the FreeBSD release
(security) branches. In addition to being faster and more
convenient than source updates, FreeBSD Update also requires
less bandwidth and is more secure than source updates via
CVSup. However, FreeBSD Update is limited; it can only
update files which were installed from an official RELEASE
image and not recompiled locally. Right now I'm publishing
binary updates for 4.7-RELEASE and 4.8-RELEASE; since my
only available box takes 3.5 hours to buildworld, I don't
have enough resources to do any more than that.</p>
<p>In the near future, I'd like to: Find someone who is
willing to donate a faster buildbox; start building updates
for other releases (at a minimum, for all "supported" FreeBSD
releases); add warnings if a file would have been updated
but can't be updated because it was recompiled locally; add
code to compare the local system against a list of "valid"
MD5 hashes for intrusion detection purposes; and add support
for cross-signing, whereby several machines could build
updates independently to protect against buildbox
compromise.</p>
</body>
</project>
<project>
<title>Porting OpenBSD's pf</title>
<contact>
<person>
<name>
<given>Max</given>
<common>Laier</common>
</name>
<email>max@love2party.net</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">
http://pf4freebsd.love2party.net</url>
<url href="http://www.benzedrine.cx/pf.html">PF homepage</url>
<url href="http://openbsd.org/faq/pf/index.html">PF FAQ</url>
</links>
<body>
<p>The project started this spring and released version 1.0 with a port
installation (security/pf) in may 2003. Version 2.0 is on the doorstep
as OpenBSD 3.4 will be released. Due to the porting efforts we were
able to reveal some bugs in the OpenBSD code and provided locking for
the PFIL_HOOKS, which we utilize. Tarball installation of a loadable
kernel module for testing can be found on the project homepage, a
patchset is in the making.</p>
<p>PF was started at OpenBSD as a substitute for ipfilter and provides
the same function set. However, in the two years it exists now, it has
gained many superior features that no other packet filter has. For a
impression take a look at the pf FAQ.</p>
<p>We hope to be eventually integrated into the base system. Before that
we have to resolve some issues with tcpdump and kame.</p>
</body>
</project>
<project>
<title>
Bluetooth stack for FreeBSD (Netgraph implementation)
</title>
<contact>
<person>
<name>
<given>Maksim</given>
<common>Yevmenkin</common>
</name>
<email>m_evmenkin@yahoo.com</email>
</person>
</contact>
<links>
<url href="http://www.geocities.com/m_evmenkin/">Latest snapshot</url>
<url href="http://bluez.sf.net">Linux BlueZ stack</url>
<url href="http://sourceforge.net/projects/openobex/">OpenOBEX</url>
</links>
<body>
<p>I'm very pleased to announce that another release is available for
download at
http://www.geocities.com/m_evmenkin/ngbt-fbsd-20030908.tar.gz.
I have also prepared patch for the FreeBSD source tree. The patch
was submitted for review to the committers.</p>
<p>Fixed few bugs in kernel modules. The ng_hci(4) and ng_l2cap(4)
modules were changed to fix issue with Netgraph timeouts. The
ng_ubt(4) module was changed to fix compilation issue on -current.</p>
<p>Improved user-space utilities. Implemented new libsdp(3). Added
new sdpcontrol(8) utility. The rfcomm_sppd(1), rfcomm_pppd(8) and
obexapp(1) were changed and now can obtain RFCOMM channel via SDP
from the server. The hccontorol(8) utility now has four new
commands. The hcsecd(8) daemon now saves link keys on the disk.</p>
<p>I've been recently contacted by few individuals who whould like to
port current FreeBSD Bluetooth code to other BSD systems (OpenBSD
and NetBSD). The work is slowly progressing towards
un-Netgraph'ing current code. In the mean time Netgraph version
will be the primary supported version of the code.</p>
</body>
</project>
<project>
<title>Rescue build infrastructure</title>
<contact>
<person>
<name>
<given>Gordon</given>
<common>Tetlow</common>
</name>
<email>gordon@FreeBSD.org</email>
</person>
<person>
<name>
<given>Tim</given>
<common>Kientzle</common>
</name>
<email>kientzle@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The rescue build infrastructure has been committed. There is one
known issue with make using both the '-s' and '-j' flags that appears
to be a bug in make. Anyone interested in tracking down should contact
us.</p>
</body>
</project>
<project>
<title>Dynamically Linked Root Support</title>
<contact>
<person>
<name>
<given>Gordon</given>
<common>Tetlow</common>
</name>
<email>gordon@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Support for a dynamically linked /bin and /sbin has been committed,
although it is not turned on by default. Adventurous users can try it
out by building /bin and /sbin using the WITH_DYNAMICROOT make flag.
More testing is needed to determine if this is going to be default for
5.2-RELEASE. If anyone would like to benchmark worldstones with and
without dynamically linked /bin and /sbin, please feel free to do so
and submit the results.</p>
</body>
</project>
<project>
<title>ACPI Status Report</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/" />
</links>
<body>
<p>Work is continuing on updating ACPI with new features as well
as bugfixing. A new embedded controller driver was written in
July with support for the ACPI 2.0 ECDT as well as more robust
polling support. Also, a buffer overflow in the ACPICA resource list
handling that caused panics for some users was fixed. Marcel
helped get acpidump(8) tested and basically working on ia64.</p>
<p>Upcoming work includes integrating ACPI notifies with devd(8),
committing user-submitted drivers for ASUS and Toshiba hotkeys,
Cx processor sleep states (so my laptop doesn't burn my lap), and
power resource support for intelligently powering down unused or idle
devices.</p>
<p>Users who have problems with ACPI are encouraged to submit a PR
and email its number to acpi-jp@jp.FreeBSD.org. Bug reports
of panics or crashes have first priority and non-working features
or missing devices (except suspend/resume problems) second.
Reports of failed suspend/resume should NOT be submitted as PRs
at this time due to most of them being a result of incomplete
device support that is being addressed. However, feel free
to mail them to the list as any information is helpful.</p>
</body>
</project>
<project>
<title>uart(4)</title>
<contact>
<person>
<name>
<given>Marcel</given>
<common>Moolenaar</common>
</name>
<email>marcel@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The uart(4) project was born out of the need to have a working
serial interface (i.e. an RS-232-C interface) in a legacy-free
configuration and after an unsuccessful attempt to convert sio(4).
The biggest problem with sio(4) is that it has been intertwined
in many ugly ways into the kernel's core. Conversion could not
happen without breaking something that invariably affects some
group of people negatively. With sio(4) as a good bad example
and a strong desire to solve multiple problems at once, the
idea of an UART (Universal Asynchronuous Receiver/Transmitter)
device that, given its generic name, could handle different
flavors of UART hardware started to settle firmly in the authors
mind.</p>
<p>The biggest challenge was of course solving the problem of the
low-level console access prior to the initialization of the bus
infrastructure and still have a driver that uses the bus access
exclusively. Along the way the problem of having an UART function
as the keyboard on sparc64 was solved with the introduction of
system devices, which also encapsulated the console as a system
device.</p>
<p>The uart(4) driver can be enhanced to support the various UART
hardware on pc98 and this is currently being worked on. Keyboard
support on sparc64 is underway as well. Plans exist for a rewrite
of the remote gdb support that uses a generic interface to allow
various drivers, including uart(4), to register itself as a
communications channel. And since uart(4) does not support multi-
port cards by itself, we likely need to either enhance puc(4) or
otherwise introduce other umbrella drivers</p>
</body>
</project>
<project>
<title>Compile FreeBSD with Intels C compiler (icc)</title>
<contact>
<person>
<name>
<given>Alexander</given>
<common>Leidinger</common>
</name>
<email>netchild@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.Leidinger.net/FreeBSD/">Some patches.</url>
</links>
<body>
<p>Since I ported icc to FreeBSD I wanted to build FreeBSD with icc. Now
with icc 7.1 (and some patches) it is possible. There are still some bugs,
e.g. NFS doesn't work with an icc compiled kernel, IP seems to be fragile,
and some advanced optimizations trigger an ICE (Intel is working on it).
At the moment I'm waiting for our admins to install icc on the FreeBSD
cluster (we got a commercial license from Intel, so we are allowed to
distribute binaries which are compiled with icc), after that I will try
to convince some people with more knowledge of the IP and NFS parts of
the kernel to debug the remaining problems. When the icc compiled kernel
seems to work mostly bugfree the userland will get the porting focus.
Interested people may try to do a build of the ports tree with icc
independently from the status of the porting of the userland... if this
happens at the FreeBSD cluster, we would also be allowed to distribute
the binaries.</p>
<p>Benefits include: another set of compiler errors (debugging help),
more portable source, and code which is better optimized for a P4 (gcc
has some drawbacks in this area)</p>
</body>
</project>
<project>
<title>KDE FreeBSD Project</title>
<contact>
<person>
<name>
<given>KDE-FreeBSD</given>
<common>Mailinglist</common>
</name>
<email>kde@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://freebsd.kde.org/" />
</links>
<body>
<p>The FreeBSD ports were updated to KDE 3.1.4, another bug- and
security-fixes release. With this update, the QT port was updated
to version 3.2. Both will be included in FreeBSD 4.9.
Significant work was spent to fix KDE on FreeBSD-CURRENT after the
removal of the gcc -pthread Option. Automatic package builds from
KDE CVS continued to ensure and improve the quality of the upcoming
KDE 3.2 release.</p>
<p>Future: Work is in progress to setup a new server for hosting the
KDE-FreeBSD Website, Repository and another KDE CVS mirror. With
help from Marcel Moolenaar the project will try to make KDE compile
and working on the Intel IA64. And last but not least efforts are
being made to fix the currently broken kdesu program.</p>
</body>
</project>
<project>
<title>WifiBSD Status Report</title>
<contact>
<person>
<name>
<given>Jon</given>
<common>Disnard</common>
</name>
<email>masta@wifibsd.org</email>
</person>
</contact>
<links>
<url href="http://www.wifibsd.org">www.wifibsd.org</url>
</links>
<body>
<p>WifiBSD is a miniture version of FreeBSD for wireless applications.
Originally for the Soekris Net45xx line of main-boards, but is now
capable of being targeted to any hardware/architecture FreeBSD itself
supports. Although not feature complete, WifiBSD is expected to be
ready for 5.2-RELEASE. The design goal is to meet, or exceed, the
functionality of commercial/consumer 802.11 wireless gear. Features
that need attention (to name just a few) are: http interface, consol
menu interface, and installation. Volunters are welcome.</p>
</body>
</project>
<project>
<title>PowerPC Port</title>
<contact>
<person>
<name>
<given>Peter</given>
<common>Grehan</common>
</name>
<email>grehan@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Work has restarted after a hiatus. Current focus is on getting
loadable modules working, NEWBUSing the NetBSD dbdma code, and
completing the BMAC ethernet driver.</p>
<p>There is a huge amount of work to do. Volunteers more than welcome!</p>
</body>
</project>
<project>
<title>AMD64 Porting</title>
<contact>
<person>
<name>
<given>Peter</given>
<common>Wemm</common>
</name>
<email>peter@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The last known bug that prevented AMD64 machines completing a
full release has been fixed - one single character error that
caused ghostscript to crash during rendering diagrams. SMP work
is nearing completion and should be committed within the next few
days. The SMP code uses the ACPI MADT table based on John Baldwin's
work-in-progress there for i386. We need to spend some time on
low level optimization because there are several suboptimal places
that have been ignored for simplicity, context switching in
particular. MTRR support has been committed and XFree86 can use
it. cvsup now works but the ezm3 port has not been updated yet.
The default data segment size limit is 8GB instead of 512M, and
the (primitive) i386 binary emulation support knows how to lower
the rlimits for executing 32 bit binaries.</p>
<p>Notable things missing still: Hardware debug register support
needs to be written; gdb is still being done as an external
set of patches relative to the not-yet-released FSF gdb tree;
DDB does not disassemble properly; DDB cannot do stack traces
without -fno-omit-frame-pointer - a stack unwinder is needed;
i386 and amd64 linux binary emulation is needed, and the i386
FreeBSD binary emulation still needs work - removing the
stackgap code in particular.</p>
<p>The platform in general is very reliable although a couple of
problems have been reported over the last week. One appears to
be a stuck interrupt, but all that code has been redone for SMP
support.</p>
</body>
</project>
<project>
<title>bsd.java.mk version 2.0</title>
<contact>
<person>
<name>
<given>Ernst</given>
<common>De Haan</common>
</name>
<email>znerd@FreeBSD.org</email>
</person>
<person>
<name>
<given>Herve</given>
<common>Quiroz</common>
</name>
<email>herve.quiroz@esil.univ-mrs.fr</email>
</person>
</contact>
<links>
<url href="http://www.esil.univ-mrs.fr/~hquiroz/freebsd/bsd.java.mk-2.0.html">Project homepage</url>
</links>
<body>
<p>The FreeBSD Java community has started an effort to improve the
current framework for Java-based ports. The main objective is the
automation of JDK/JRE build and run dependency checking.</p>
<p>The original version was aimed to ease the life of porters. Although
it has proved to be useful and reliable to a great extend, we are
currently working on a new version. We intend to reach a high degree
of flexibility to cope with the recent increase of available JDK/JRE
flavors. Furthermore, the new version will be easier to maintain,
which means improved reliability, and hopefully more frequent
updates.</p>
</body>
</project>
<project>
<title>FreeBSD Java Project</title>
<contact>
<person>
<name>
<given>Greg</given>
<common>Lewis</common>
</name>
<email>glewis@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/java/">FreeBSD Java Project</url>
</links>
<body>
<p>The BSD Java Porting Team has recently reached an exciting milestone
with the release of the first "Diablo" JDK and JRE courtesy of the
FreeBSD Foundation. The release of Diablo Caffe and Diablo Latte
1.3.1 was the first binary release of a native FreeBSD JDK since
1.1.8 and marks an important step forward in FreeBSD Java support.</p>
<p>The team is continuing development work, with a focus on achieving
a compliant JDK 1.4 release in the near future.</p>
</body>
</project>
<project>
<title>ATAPI/CAM Status Report</title>
<contact>
<person>
<name>
<given>Thomas</given>
<common>Quinot</common>
</name>
<email>thomas@FreeBSD.org</email>
</person>
</contact>
<body>
<p>With the introduction of ATAng, some users of ATAPI/CAM have
experienced various problems. These have been mostly tracked down
to issues in the new ATA code, as well as two long-standing problems
in portions of the CAM layer that are rarely exercised with
"real" SCSI SIMs. This has also been an occasion to cleanup
ATAPI/CAM to make it more robust, and to enable DMA for devices
accessed through it, resulting in improved performances.</p>
</body>
</project>
<project>
<title>jpman project</title>
<contact>
<person>
<name>
<given>Kazuo</given>
<common>Horikawa</common>
</name>
<email>horikawa@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.jp.FreeBSD.org/man-jp/">jpman project</url>
<url href="ftp://daemon.jp.FreeBSD.org/pub/FreeBSD-jp/man-jp/packages-5.1.0/ja-man-doc-5.1.tbz">package ja-man-doc-5.1.tbz</url>
</links>
<body>
<p>We have released Japanese translation of 5.1-RELEASE online manual
pages on June 10.</p>
</body>
</project>
<project>
<title>FreeBSD ports monitoring system</title>
<contact>
<person>
<name>
<given>Mark</given>
<common>Linimon</common>
</name>
<email>linimon_at_lonesome_dot_com</email>
</person>
</contact>
<links>
<url href="http://lonesome.dyndns.org:4802/bento/errorlogs/index.html">
FreeBSD ports monitoring system</url>
</links>
<body>
<p>Several months ago, I took it upon myself to to try present the
information contained on <a href="http://bento.FreeBSD.org">the bento
build cluster</a> to be presented in a more user-friendly fashion; that
is, to be browsed by error type, by maintainer, and so forth. An early
addition was code to attempt to classify ports PRs by either "existing
port" (after assiging the most likely category and portname); "new port";
"framework" (e.g. bsd.port.mk changes); and "unknown". Various columns
about the ports PRs were added to the reports.</p>
<p>The initial intent of this was to make life easier for ports
maintainers; however, the "general" reports are also useful to anyone who
just wants to, e.g., find out if a particular port is working on their
particular architecture and OS combination before downloading it. Those
with that general interest should start with the
<a href="http://lonesome.dyndns.org:4802/bento/errorlogs/portoverview.py">
overview of one port</a>.</p>
</body>
</project>
<project>
<title>kgi4BSD Status Report</title>
<contact>
<person>
<name>
<given>Nicholas</given>
<common>Souchu</common>
</name>
<email>nsouch@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/~nsouch/kgi4BSD"> Project URL</url>
</links>
<body>
<p>A lot of work done since last report: site reworked completely (see new
URL), console design with console message in text or graphic modes
implemented, implementation of a compatibility layer to compile Linux
fbdev drivers with more or less changes in the original driver
(experimental).</p>
<p>Except some memory allocation bugs, X (XGGI based on XFree 3.3.6) is
now working with the same driver as the console. A basic terminal has
now to be implemented.</p>
<p> Volunteers are welcome to the project...</p>
</body>
</project>
<project>
<title>Device_t locking</title>
<contact>
<person>
<name>
<given>Warner</given>
<common>Losh</common>
</name>
<email>imp@FreeBSD.org</email>
</person>
</contact>
<body>
<p>A number of races have been identified in locking device_t.
Most of the races have been identified in making device_t have to
do with how drivers are written. Efforts are underway to identify
all the races, and to contact the authors of subsystems that can
help the drivers. Of special concern is the need for the driver
to ensure that all threads are completely out of the driver code
before detach() finishes. Of additional concern is making sure
that all sleepers are woken up before certain routines are called
so that other subsystems can ensure the last condition and leave
no dangling references. Locking device_t is relatively straight
forward apart from these issues. Towards the end of proper
locking, sample strawmen drivers are being used to work out what,
exactly proper is. Once these issues are all known and documented
in the code, efforts will be made to update relevant documentation
in the tree. There are many problems with driver locking that has
been done to date, but until we nail down how to write a driver in
current, it will be premature to contact specific driver writers
with specific concerns.</p>
</body>
</project>
<project>
<title>Cryptographic Support</title>
<contact>
<person>
<name>
<given>Sam</given>
<common>Leffler</common>
</name>
<email>sam@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Support for several new crypto devices was added. The SafeNet 1141 is a
medium performance part that is not yet available on retail products. The
Hifn 7955 and 7956 parts are starting to appear on retail products that
should be available by the end of the year. Both devices support AES
encryption. Support for public key operations for the SafeNet devices was
recently done for OpenBSD and will be backported. Public key support for
the Hifn parts is planned.</p>
<p>A paper about the performance work done on the cryptographic subsystem
was presented at the Usenix BSDCon 2003 conference and received the best
paper award.</p>
<p>NetBSD recently imported the cryptographic subsystem.</p>
</body>
</project>
<project>
<title>Release Engineering Status</title>
<contact>
<person>
<name>
<given>Scott</given>
<common>Long</common>
</name>
<email>re@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The release of 4.9 is just around the corner and offers Physical Address
Extensions (PAE) for x86 along with the same world-class stability and
performance that is expected from the 4-STABLE series. As always, don't
forget to purchase a copy of the CD set from your favorite FreeBSD
vendor.</p>
<p>FreeBSD 5.1 was released in June and offered vastly improved
stability over 5.0 along with a working implementation of Kernel
Scheduled Entities, allowing for true multithreading of applications
across multiple CPUs. FreeBSD 5.2 will be released by the end of 2003
and will focus on improved network and overall performance.</p>
</body>
</project>
<project>
<title>Wireless Networking Support</title>
<contact>
<person>
<name>
<given>Sam</given>
<common>Leffler</common>
</name>
<email>sam@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Numerous bugs have been fixed since the last status report (and of
course a few new ones added). Progress on improved security has been
slowed by other work. But new features and fixes are coming in from
other groups that are now sharing the code. In particular NetBSD
recently imported the revised 802.11 layer and the Linux-based MADWIFI
project is using it too (albeit in an older form). The MADWIFI users
have already contributed features such as fragmentation reassembly of
802.11 frames and improved signal monitoring. Power save polling and
an improved rate control algorothm are expected to come in from the
NetBSD folks. WPA support is still in the plans; the best estimate is
that work on that will start in January.</p>
</body>
</project>
<project>
<title>Network Subsystem Locking and Performance</title>
<contact>
<person>
<name>
<given>Sam</given>
<common>Leffler</common>
</name>
<email>sam@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The purpose of this project is to improve performance of the network
subsystem. A major part of this work is to complete the locking of the
networking subsystem so that it no longer depends on the "Giant lock"
for proper operation. Removing the use of Giant will improve
performance and permit multiple instances of the network stack to
operate concurrently on multiprocessor systems.</p>
<p>This project started in August. The emphasis has been on locking the
"lower half" of the networking code so that packet forwarding through the
IPv4 path can operate without the Giant lock as part of the 5.2 release.
To this end locking was added to several network interface drivers and
much of the "middleware" code in the network was locked (e.g. ipfw,
dummynet, then routing table, multicast routing support, etc). Work
towards this goal is still ongoing but should be ready for 5.2. A
variety of test systems have been running for several months without the
Giant lock in the network drivers and IP layer.</p>
<p>Past the 5.2 release Giant will be removed from the "upper half" of the
network subsystem and the socket layer. Once this is done the plan is to
measure and improve performance (though some work of this sort is always
happening). The ultimate goal is a system that performs at least as well
as 4.x for normal use on uniprocessor systems. On multiprocessor systems
we expect to see significantly better performance than 4.x due to greater
concurrency and reduced latency.</p>
</body>
</project>
</report>
|
