aboutsummaryrefslogtreecommitdiff
path: root/en/news/status/report-2002-11-2002-12.xml
blob: 7cf255898c4c14022a8a28d006dfd5acdd5f0eed (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
<!-- $FreeBSD: www/en/news/status/report-nov-2002-dec-2002.xml,v 1.4 2004/04/05 14:46:17 phantom Exp $ -->

<report>
  <date>
    <month>November-December</month>
    <year>2002</year>
  </date>

  <section>
    <title>Introduction:</title>

    <p>At long last, FreeBSD 5.0 is here.  Along with putting the final
      polish on the tree, FreeBSD developers somehow found the time to
      work on other things too.  IA64 took some major steps towards
      working on the Itanium2 platform, an effort was started to
      convert all drivers to use busdma and ban vtophys(), hardware
      crypto support and DEVD hit the tree, NewReno was fixed and 
      effort began on locking down the network layer of the kernel.
      Also high performance, modular scheduler started taking shape
      and will be a welcome addition to the kernel soon.</p>

    <p>Looking forward, the focus will be on stabilizing and
      improving the performance of 5.0.  The RELENG_5 (aka 5-STABLE)
      branch will be created once we've reached our goals in this
      area, so hopefully we will get there quickly.  Meanwhile,
      preparations for the next release from the 4.x series, 4.8,
      will begin soon.  Of course, the best way to get 5.x to
      stabilize os to install and run it!</p>

    <p>Thanks,</p>

    <p>Scott Long, Robert Watson</p>
  </section>

<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 all kernel modules and few userland
      tools made it to the FreeBSD source tree. Many thanks to Julian
      Elischer.</p>

    <p>Unfortunately no big changes since the last report. Some minor problems
      have been discovered and patches are available on request. I will prepare
      all the patches and submit them to Julian for review.</p>

    <p> OBEX server and client (based on OpenOBEX library) is almost complete.
      I'm currently doing interoperability testing. If anyone has hardware and
      time please contact me. The HCI security daemon has been implemented and
      tested with Sony Ericsson T68i cell phone and Windows stack. It is now
      possible to setup secure Bluetooth connections.</p>

    <p>A few people have complained about RFCOMM daemon. These individuals want
      to use GPRS and Bluetooth enabled cell phone to access Internet. If you
      have this problem please contact me for possible workaround. My next goal
      is to get robust RFCOMM implementation to address all these issues.</p>
  </body>
</project>

<project>
  <title>TrustedBSD Project: Access Control Lists</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>Largely bug-fixing and userland application tweaks; new
      interfaces were added to manipulate ACLs on extended attributes;
      bugs were fixed in ls relating to ACL flagging.  Patches to
      teach cp, mv, gzip, bzip, and other apps about ACL preservation
      are in testing and review.  tunefs flags were added to ease
      configuration of ACLs, especially on UFS2 file systems.</p>
    <p>Possible changes to make use of Linux/Solaris umask semantics
      are under consideration: right now we implement verbatim
      POSIX.1e/IRIX merging of the umask, ACL mask, and requested
      creation mode during file, device, fifo, and directory creation.
      Solaris and the most recent Linux patches ignore the umask in
      the context of a default ACL; this requires some rearrangement
      of umask handling in our VFS, although the results would be
      quite useful.  We're exploring how to do this in a low impact
      way.</p>
  </body>
</project>

<project>
  <title>TrustedBSD Project: MAC Framework</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>Framework changes:</p>
    <p>Instrument KLD system calls (module and kld load, unload, stat)
      Instrument NFSd system call.  Instrument swapoff(2).
      Instrument per-architecture privileged parts of sysarch().
      Make use of condition variables to allow callers to wait for the
      framework to "unbusy" when loading/unloading policies, rather than
      returning EBUSY.  Store mount pointer in devfs_mount structure for
      use by policies.  Improve handling of labels in loopback interface
      "re-align" packet copy case.  Provide full paths on devfs object
      creations to help policies label them properly (not merged).
      Experimentation with moving MAC labels into m_tags (not merged).
      NFS server now uses real ucreds, not hacked up ucreds,
      meaning we can start laying the groundwork for enforcement on
      NFS operations. (not merged)</p>

    <p>Policy changes</p>
    <p>LOMAC: mac_lomac replaces lomac (LOMAC now uses the MAC Framework),
      SEBSD: Improved support for devfs labeling based on SELinux genfs.
      Handling of hard link checks.  Support export of process transition
      information for login and others using sysctl.  Login now prompts
      for roles.  Allow policy reload. TTY labeling.  Locking adaptation
      from Linux.  Many, many policy adaptations and fixes.  We can
      now boot in enforcing mode!  mac_bsdextended: fix a bug in which
      VAPPEND wasn't mapped to VWRITE, so opens with the O_APPEND bug
      failed improperly.</p>

    <p>Userland changes</p>
    <p>setfmac(8) now supports a setfsmac(8) execution mode, which accepts
      initial labeling specification files.  Supports an SELinux compatibility
      mode so it can accept SELinux label specfiles using the SEBSD module.
      sendmail(8) now sets user labels as part of the context switch for mail
      delivery.</p>

    <p>Documentation changes</p>
    <p>Man page updates for MAC command line tools, modules, admin hints, etc.
      Updates to the FreeBSD Developer's Handbook chapter on MAC policies
      and entry points.  MAC section in FreeBSD Handbook.</p>
  </body>
</project>

<project>
  <title>busdma driver conversion project</title>

  <contact>
    <person>
      <name>
	<given>Maxime</given>

	<common>Henrion</common>
      </name>

      <email>mux@FreeBSD.org</email>
    </person>
  </contact>

  <links>
    <url href="http://www.FreeBSD.org/projects/busdma/" />
  </links>

  <body>
    <p>This project has been coming along pretty well.  The amd(4) and
      xl(4) drivers have now been converted to use the busdma API,
      sparc64 got the bus_dmamap_load_mbuf() and bus_dmamap_load_uio()
      functions, and the gem(4) and hme(4) drivers have been updated
      to use bus_dmamap_load_mbuf() instead of bus_dmamap_load().</p>

    <p>A lot more still needs to be done, as shown on the project's
      page.  A fair number of conversions are on their way though,
      and we can expect a fair number of drivers to be converted
      soon, thanks to all the developers who are working on this
      project.</p>
  </body>
</project>

<project>
  <title>FreeBSD C99 &amp; POSIX Conformance Project</title>

  <contact>
    <person>
      <name>
	<given>Mike</given>
        <common>Barcroft</common>
      </name>

      <email>mike@FreeBSD.org</email>
    </person>
    <person>
      <name>
        <common>FreeBSD-Standards Mailing List</common>
      </name>

      <email>standards@FreeBSD.org</email>
    </person>
  </contact>

  <links>
    <url href="http://www.FreeBSD.org/projects/c99/" />
    <url href="http://people.FreeBSD.org/~schweikh/posix-utilities.html" />
  </links>

  <body>
    <p>The POSIX Utility Conformance in FreeBSD list (link above) has
      been updated to reflect current reality.  Not much work remains
      to complete base utility conformance.</p>

    <p>On the API front, grantpt(), posix_openpt(), unlockpt(),
      wordexp(), and wordfree() were implemented.  The header
      &lt;wordexp.h&gt; was added.</p>

    <p>There are currently about 40 unassigned tasks on our project's
      status board ranging from documentation, utilities, to kernel
      hacking.  We would encourage any developers looking for something
      to work on to check out the status board and see if anything
      interests them.</p>
  </body>
</project>

<project>
  <title>Hardware Crypto Support Status</title>

  <contact>
    <person>
      <name>
        <given>Sam</given>
        <common>Leffler</common>
      </name>

      <email>sam@FreeBSD.org</email>
    </person>
  </contact>

  <body>
    <p>The goal of this project is to import the OpenBSD kernel-level crypto
      subsystem. This facility provides kernel- and user-level access to
      hardware crypto devices for the calculation of cryptographic hashes,
      ciphers, and public key operations. The main clients of this facility
      are the kernel RNG (/dev/random), network protocols (e.g. IPsec), and
      OpenSSL (through the /dev/crypto device).</p>

    <p>This work will be part of the 5.0 release and has been committed to
      the -stable source tree for inclusion in the 4.8 release.</p>

    <p>Recent work has focused on improving performance. System statistics are
      now maintained and an optional profiling facility was added for
      analyzing performance. Using this facility the overhead for using the
      crypto API has been significantly reduced.</p>

    <p>The ubsec (Broadcom) driver was changed to significantly improve
      performance under load. In addition several memory leaks were fixed in
      the driver and the public key support was enabled for use.</p>

    <p>Upcoming work will focus on load-balancing requests across multiple
      crypto devices and integrating OpenSSL 0.9.7 which will automatically
      enable application use of crypto hardware.</p>
  </body>
</project>

<project>
  <title>DEVD</title>

  <contact>
    <person>
      <name>
	<given>Warner</given>
	<common>Losh</common>
      </name>

      <email>imp@FreeBSD.org</email>
    </person>
  </contact>

  <body>
    <p>Devd has been integrated into FreeBSD 5.0-RELEASE.  The
    integrated code supports a range of configuration options.  The
    config files are fully parsed now and their actions are
    performed.</p>

    <p>Future work in this area is likely to be limited to improving
     the devctl interface.  /dev/devctl likely will be a cloneable
     device in future versions.  Individual device control via devctl
     is also planned.</p>
  </body>
</project>

<project>
  <title>Donations Team Status Report</title>

  <contact>
    <person>
      <name>
	<given>Michael</given>
	<common>Lucas</common>
      </name>

      <email>donations@FreeBSD.org</email>
    </person>
  </contact>

  <links>
    <url href="http://www.FreeBSD.org/donations/">Donations main page</url>
    <url href="http://www.FreeBSD.org/donations/wantlist.html">FreeBSD
      developer wantlist</url>
    <url href="http://www.FreeBSD.org/donations/donors.html">
      completed donations</url>
  </links>

  <body>
    <p>The Donations project expedited several dozen donations during
      2002, and was able to place most of what was offered.  We still
      are in dire need of SMP and Sparc systems.  You can see
      information on our needs and donations that have been handled by
      the team on the donations web page.</p>

    <p>We are relying increasingly upon the developer wantlist to
      place items offered to the Project, and using the commit
      statistics to help place items.  As such, active committers who
      ask for what they want beforehand have a decent chance of
      getting it.  Less active committers, and committers who do not
      ask for what they want, will be lower in our priorities but will
      not be excluded.</p>

    <p>We are in the process of streamlining the tax deduction process
      for donations, and hope to have news on that shortly.  We are
      also always working to accelerate and reduce our internal
      processes, to get the most equipment in the hands of the most
      people as quickly as possible.</p>

    <p>I especially want to thank David O'Brien and Tom Rhodes for
      stepping up and making the team far more successful.  Also, the
      FreeBSD Foundation has been quite helpful in handling
      tax-deductible contributions.</p>
  </body>
</project>



<project>
  <title>Fast IPsec Status</title>

  <contact>
    <person>
      <name>
        <given>Sam</given>
        <common>Leffler</common>
      </name>

      <email>sam@FreeBSD.org</email>
    </person>
  </contact>

  <body>
    <p>The main goal of this project is to modify the IPsec protocols to use
      the kernel-level crypto subsystem imported from OpenBSD (see elsewhere).
      A secondary goal is to do general performance tuning of the IPsec
      protocols.</p>

    <p>This work will be part of the 5.0 release.  Performance has been improved
      due to work on the crypto subsystem.</p>
  </body>
</project>

<project>
  <title>FFS volume label support</title>

  <contact>
    <person>
      <name>
	<given>Gordon</given>
	<common>Tetlow</common>
      </name>

      <email>gordon@FreeBSD.org</email>
    </person>
  </contact>

  <links>
    <url href="http://people.FreeBSD.org/~gordon/patches/volume.diff">Current patch set.</url>
  </links>

  <body>
    <p>The goal of the project is to use a small amount of space in the FFS
      superblock to store a volume label of the user's choice. A GEOM module
      will then expose the volume labels into a namespace in devfs.  The idea
      is to make it easier to manage filesystems across disk swaps and
      movement from system to system.</p>

    <p>At this point, everything pretty much works. I've submitted parts of
      the patch to respective subsystem maintainers for review. There are some
      issues with namespace collision that I haven't addressed yet, but the
      basic functionality is there</p>
  </body>
</project>

<project>
  <title>French FreeBSD Documentation Project</title>
  <contact>
    <person>
      <name>
        <given>Sebastien </given>
        <common>Gioria</common>
      </name>

      <email>gioria@FreeBSD.org</email>
    </person>
    <person>
      <name>
        <given>Marc </given>
        <common>Fonvieille</common>
      </name>
      <email>blackend@FreeBSD.org</email>
    </person>
    <person>
      <name>
        <given>St&#233;phane</given>
        <common>Legrand</common>
      </name>
      <email>stephane@FreeBSD.org</email>
    </person>
  </contact>

  <links>
    <url href="http://www.freebsd-fr.org">The French FreeBSD Documentation Project.</url>
    <url href="http://www.freebsd-fr.org/index-trad.html">The FreeBSD Web Server translated in French.</url>
    <url href="http://people.FreeBSD.org/~blackend/doc/fr_FR.ISO8859-1/books/handbook/"> Translation of the hanbook.</url>
    <url href="http://www.FreeBSD-fr.info">French Daemon News like web site.</url>
  </links>

  <body>
    <p>Most of the articles are translated too.  Marc is still translating the
      handbook, 60% is currently translated.  St&#233;phane has began the
      integration of our French localization web site in the US CVS Tree.
      S&#233;bastien is still maintaining the Release Notes.</p>

    <p>We launched a new site, www.FreeBSD-fr.info, consisting in a French
      Daemon News like site.  Netasq have donated our new server; we will
      install it in a new hosting provider in the few next weeks.  One of the
      big job now is the translation of the FAQ, and the big
      project will be the manual pages.</p>
  </body>
</project>

<project>
  <title>FreeBSD GNOME Project</title>

  <contact>
    <person>
      <name>
	<given>Joe</given>
	<common>Marcus</common>
      </name>

      <email>marcus@FreeBSD.org</email>
    </person>
    <person>
      <name>
	<given>Maxim</given>
	<common>Sobolev</common>
      </name>

      <email>sobomax@FreeBSD.org</email>
    </person>
    <person>
      <name>
        <given>Adam</given>
	<common>Weinberger</common>
      </name>

      <email>adamw@FreeBSD.org</email>
    </person>

  </contact>

  <links>
    <url href="http://www.FreeBSD.org/gnome/">FreeBSD GNOME Project
      Homepage.</url>
  </links>

  <body>
    <p>Since the ports tree has been frozen for most of this reporting period,
      there have not been too many GNOME updates going into the official CVS
      tree.  However, development has not stopped.  GNOME 2.2 is nearing
      completion, and quite a few FreeBSD users have stepped up to test the
      GNOME 2.1 port sources from the
      <a href="http://www.marcuscom.com:8080/cgi-bin/cvsweb.cgi">MarcusCom
      CVS repository</a>.  If anyone else is interested, follow the
      instructions on the aforementioned cvsweb URL, and checkout the "ports"
      module.</p>

    <p>The upcoming FreeBSD 5.0-RELEASE will be the first release to have the
      GNOME 2.0 desktop as the default GNOME desktop choice.  During the
      previously mentioned ports freeze, all the GNOME 2 ports were fixed up
      so that they build and package on both i386 and Alpha platforms.  Alas,
      the one port that will not make the cut for Alpha is Mozilla.  There are
      still problems with the xpcom code, but work is ongoing to get a working
      Alpha port.</p>

    <p>Finally, the FreeBSD Mono (an OpenSource C&#35; runtime) port has also
      received some new life.  Mono has been updated to 0.17 (the latest
      released version), and Juli Mallett has ported gtk-sharp (GTK+ bindings
      for C&#35;).</p>
  </body>
</project>

<project>
  <title>FreeBSD/ia64 Status</title>

  <contact>
    <person>
      <name>
	<given>Peter</given>
	<common>Wemm</common>
      </name>

      <email>peter@FreeBSD.org</email>
    </person>
    <person>
      <name>
	<given>Marcel</given>
	<common>Moolenaar</common>
      </name>

      <email>marcel@FreeBSD.org</email>
    </person>
  </contact>

  <links>
    <url href="http://people.FreeBSD.org/~peter/ia64.diff" />
    <url href="http://www.FreeBSD.org/platforms/ia64/" />
  </links>

  <body>
    <p>The ia64 port is up and running on the new Itanium2 based hp
      machines thanks to a lot of hard work by Marcel Moolenaar.  So
      far we are running on the hp rx2600 as these were the machines
      graciously donated by Hewlett-Packard and Intel.  We had a
      prototype Intel Tiger4 system for a while, but we had to return
      the machine and we do not know if it currently runs.  Most of
      the changes necessary to run these are sitting in the perforce
      tree and are not in the -current or RELENG_5 cvs tree.  As a
      result, the cvs derived builds (-current and the 5.0-RC series
      and presumably 5.0-RELEASE) are only usable on obsolete Itanium1
      systems.</p>

    <p>Lots of other stability and functionality fixes have been made
      over the last few months, including initial libc_r support.  The
      OS appears to be stable enough for sustained workloads - it is
      building packages now, for example.  We still do not have gdb
      support, even for reading core files.</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>
  </links>

  <body>
     <p>We have been updating our Japanese translated manual pages to
       RELENG_5 based.  All existing entries have been updated, but 15
       exceptions are not, most of which require massive update.  We
       will also need to add translations which did not exist on RELENG_4.</p>
  </body>
</project>

<project>
  <title>KGI/FreeBSD 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/ggiport.html" />
    <url href="http://www.kgi-project.org" />
  </links>

  <body>
    <p>KGI (Kernel Graphic Interface) is a kernel infrastructure providing user
      applications with means to access hardware graphic resources (dma,
      irqs, mmio). KGI is already available under Linux as a separate
      standalone project. The KGI/FreeBSD project aims at integrating KGI
      in the FreeBSD kernel.</p>

    <p>KGI/FreeBSD has been recently donated 2 PCI graphic cards (Matrox
      Millenium II and a coming Mach64) and other have been proposed.
      Please see the FreeBSD web pages for details.  Thanks to donation@ for
      organizing and promoting donations. Thanks to the donators for their
      contribution to KGI/FreeBSD.</p>

    <p>KGI/FreeBSD progressed fine the last months. Most of the VM issues for
      mapping HW resources in user space have been addressed and a first
      attempt of coding was made. This prototyping raised some API
      compatibility problems with the current Linux implementation and was
      discussed heavily on the kgi devel lists. Ask if you're
      interested in such issues, I'll be pleased to share them.</p>

    <p>Most of coding is now done. Let's start debugging!</p>
  </body>
</project>

<project>
  <title>SMP locking for network stack</title>

  <contact>
    <person>
      <name>
        <given>Jeffrey</given>
        <common>Hsu</common>
      </name>

      <email>hsu@FreeBSD.org</email>
    </person>
  </contact>

  <body>
    <p> Work is ongoing to continue to lock up the network stack.
      Recently, the focus has been on the IP stack.  The plan there
      involves a series of inter-related pieces to lock up the
      ifaddr ref count, the inet list, the ifaddr uses, the ARP code,
      the routing tree, and the routing entries.  We are over 3/5 of
      the way done down this path.</p>

    <p>In addition to TCP and UDP, the other networking protocols
      such as raw IP, IPv6, AppleTalk, and XNS need to be locked up.
      Around 1/4 these remaining protocols have been locked and
      will be committed after the IP stack is locked.</p>

    <p>The protocol independent socket layer needs to be locked and
      operating correctly with the protocol dependent locks.  This
      part is mostly done save for much needed testing and code cleanup.</p>

    <p>Finally, a pass will be need to be made to lock up the devices drivers
      and various statistics counters.</p>
  </body>
</project>

<project>
  <title>TCP congestion control</title>

  <contact>
    <person>
      <name>
        <given>Jeffrey</given>
        <common>Hsu</common>
      </name>

      <email>hsu@FreeBSD.org</email>
    </person>
  </contact>

  <links>
  </links>

  <body>
    <p>This effort fixes some outstanding problems in our TCP
      stack with regard to congestion control.  The first
      item is to fix our NewReno implementation.  Following that,
      the next urgent correction is to fix a problem involving window updates
      and dupack counts.  When that stabilizes, we will then change
      the recovery code to make use of SACK information.
      Eventually, this project will update the BSD stack to add Limited Transmit
      and other new internet standards and standards-track improvements.</p>
  </body>
</project>

<project>
  <title>FreeBSD Package Cluster work</title>

  <contact>
    <person>
      <name>
	<given>Kris</given>
	<common>Kennaway</common>
      </name>

      <email>kris@FreeBSD.org</email>
    </person>
  </contact>

  <links>
    <url href="http://bento.FreeBSD.org/" />
  </links>

  <body>
    <p>The 3 FreeBSD package clusters (i386, alpha, sparc64) have been
      unified to run from the same master machine, instead of using 3
      separate masters.  This has freed up some machine resources to
      use as additional client machine, as well as simplifying
      administrative overheads.  Build logs for all 3 architectures
      can now be found on the http://bento.FreeBSD.org webpage.  The
      sparc64 package cluster now has 3 build machines (an u5 and two
      u10s), and an ia64 cluster is about to be created.</p>

    <p>Package builds now keep track of how many sequential times a
      port has failed to build (html summaries are available on the
      bento website).  This allows tracking of ports which have
      suddenly become broken (e.g. due to a bad upgrade, or due to
      changes in the FreeBSD source tree), and in the future will be
      used to send out notifications to port maintainers when their
      port fails to build 5 times in a row.  This feature is currently
      experimental, and further code changes will be needed to
      stabilize it.</p>      
  </body>
</project>

<project>
  <title>Wireless Networking Status</title>

    <contact>
      <person>
        <name>
          <given>Sam</given>
          <common>Leffler</common>
        </name>

        <email>sam@FreeBSD.org</email>
      </person>
    </contact>

  <body>
  <p>The goal of this project is to improve the wireless networking support in
    the system.  By the time of this report the 802.11 link layer code should
    be committed.  A version of the wi driver that uses this code should be
    committed shortly.  Conversion of other drivers is planned as are drivers
    for new devices.</p>

  <p>Support for 802.1x/EAP is the next planned milestone (both as a
    supplicant and authenticator).</p>
  </body>
</project>

<project>
  <title>FreeBSD Release Engineering</title>

  <contact>
    <person>
      <name>
	<given>Scott</given>
	<common>Long</common>
      </name>

      <email>re@FreeBSD.org</email>
    </person>
  </contact>

  <links>
    <url href="http://www.FreeBSD.org/releng/index.html">Release Engineering
      Homepage</url>
  </links>

  <body>
    <p>November and December were especially busy for the release engineering
      team.  Scott Long joined the team to help with secretary and
      communications tasks while Brian Somers bowed out to focus on other
      projects.</p>

    <p>FreeBSD 5.0-DP2 was released in November after much delay and
      anticipation, and marked the final milestone needed for 5.0 to
      become a reality.  Shortly after that, we imposed a code freeze on
      the HEAD branch of CVS and released 5.0-RC1.  Creation of the
      RELENG_5_0 branch came next, followed by the release of 5.0-RC2 from
      this branch.  At this point, enough critical problems still existed
      that we scheduled an RC3 release for the new year, and pushed the
      final 5.0-RELEASE date to mid-January.  By the time this is published,
      FreeBSD 5.0-RELEASE should be a reality.</p>

    <p>For the time being, there will not be a RELENG_5 (aka 5-STABLE)
      branch.  FreeBSD 4.x releases will continue, with 4.8 being
      scheduled for March 2003.  Release in the 4.x series will be
      lead by Murray Stokely, and releases in the 5.x series will be
      lead by Scott Long.  Once HEAD has reached acceptable performance
      and stability goals, the RELENG_5 branch will be created and HEAD
      will move towards 6.0 development.  We hope to reach this with
      the 5.1 release this spring.</p>
  </body>
</project>

<project>
  <title>SMP aware scheduler</title>

  <contact>
    <person>
      <name>
	<given>Jeff</given>
	<common>Roberson</common>
      </name>

      <email>jeff@FreeBSD.org</email>
    </person>
  </contact>

  <body>
    <p>A new scheduler will be available as an optional component along side
      the current scheduler in the 5.1 release.  It has been designed to
      work well with KSE and SMP.  Some ideas have been borrowed from solaris
      and linux along with many novel approaches.  It has O(1) performance
      with regard to the number of processes in the system.  It also has
      cpu affinity which should provide a speed boost for many applications.</p>

    <p>The scheduler has a few loose ends and lots of tuning before it is
      production quality although it is quite stable.  Please see the post
      to arch and subsequent discussion for more details.</p>
  </body>
</project>
</report>