aboutsummaryrefslogtreecommitdiff
path: root/en/news/status/report-2003-03-2003-09.xml
blob: cf42d8744f11d721460115ae85d0e70996f8dded (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
<!-- $FreeBSD: www/en/news/status/report-mar-2003-sep-2003.xml,v 1.2 2004/04/04 21:46:14 phantom Exp $ -->

<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 completly (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> Volonteers 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>