aboutsummaryrefslogtreecommitdiff
path: root/en/news/status/report-2004-01-2004-02.xml
blob: 325b7971f511fb40bf8cdebaf100a1b0e43bd544 (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
<!-- $FreeBSD: www/en/news/status/report-jan-2004-feb-2004.xml,v 1.4 2004/04/07 11:27:47 phantom Exp $ -->
<report>
  <date>
    <month>January-February</month>
    <year>2004</year>
  </date>

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

    <p>2004 started with another exciting two months for the project.
      FreeBSD 5.2 was released in early January and then quickly followed
      in February with the 5.2.1 bug-fix release.  Looking forward, we
      are expecting a late-April release date for FreeBSD 4.10, and
      mid-summer date for FreeBSD 5.3.  And don't forget to support the
      FreeBSD vendors and developers by buying a copy of the latest CD
      or DVD sets.</p>

    <p>Thanks,</p>

    <p>Scott Long</p>
  </section>

  <project>
    <title>Disk and device I/O</title>
    
    <contact>
      <person>
        <name>
          <given>Poul-Henning</given>
          <common>Kamp</common>
        </name>
        <email>phk@FreeBSD.org</email>
      </person>
    </contact>
    
    <body>
      <p>In the overall area of disk and device I/O, a significant
        milestone was reached with the implementation of proper
        reference counting on dev_t.  We are now able to properly
        allocate and free dev_t.  Cloning device drivers also had
        the job made easier for them with the addition of the unit
        number management routines.</p>
      <p>It is not quite decided which will be the next step in
        the quest for a truly SMPng I/O subsystem, but a leading
        candidate is to implement the device-access vnode bypass
        to get more concurrency in the system:  Instead of taking
        the tour through the vnodes for each i/o operation on a
        device we will go directly from the file descriptor layer to
        DEVFS/SPECFS.  In addition to Giant-less disk I/O,
        this should enable us to pull the entire tty subsystem
        and the PTY driver out from under Giant and we expect that
        to improve the "snappiness" of the system measurably.</p>
    </body>
  </project>
  <project>
    <title>The FreeBSD Dutch Documentation Project.</title>
    <contact>
      <person>
        <name>
          <given>Remko</given>
          <common>Lodder</common>
        </name>
        <email>remko@elvandar.org</email>
      </person>
    </contact>
    <body>
      <p>The Dutch Documentation Project is a ongoing project in
        translating the handbook and other documentation to the dutch
        language. Currently there is 1 active person (me) translating the
        documentation. I am currently working on the handbook/basics
        section. But i can use some more hands, please drop me an email if
        you wish to help out so that the dutch translation will speed up
        and be ready in some time.  Contact remko@elvandar.org for
        information.</p>
    </body>
  </project>
  <project>
    <title>Weekly cvs-src summaries</title>
    
    <contact>
      <person>
        <name>
          <given>Mark</given>
          <common>Johnston</common>
        </name>
        <email>mark@xl0.org</email>
      </person>
    </contact>
    <links>
      <url href="http://excel.xl0.org/FreeBSD/" />
      <url href="http://mocart.pinco.pl/FreeBSD/">Polish translations</url>
    </links>
    
    <body>
      <p>I have been producing weekly summaries of commits and the
        surrounding discussions as reported on the cvs-src mailing list.
        These summaries are posted to -current on Sunday evenings and
        archived on the Web.  The reception has been overwhelmingly good.
        As of the end of February, Polish translations are being produced
        by Lukasz Dudek and Szymon Roczniak; they are also
        planning to translate the older summaries.</p>
    </body>
  </project>
  <project>
    <title>libarchive/bsdtar</title>
    <contact>
      <person>
        <name>
          <given>Tim</given>
          <common>Kientzle</common>
        </name>
        <email>kientzle@FreeBSD.org</email>
      </person>
    </contact>
    <links>
      <url href="http://people.FreeBSD.org/~kientzle/"/>
    </links>
    <body>
      <p>libarchive, with complete documentation, has been committed to
        -CURRENT.  bsdtar should follow soon.  For a few months, gtar
        and bsdtar will both be available in the base system.  Once
        bsdtar is in the tree, I hope to resume work on libpkg and my
        pkg_add rewrite.</p>
      
      <p>Note that bsdtar is not an exact replacement for gtar: it does
        some things better (reads/writes standard formats, archive ACLs
        and file flags, detects format and compression automatically),
        some things worse (does not handle multi-volume archives or
        sparse files) and a few things just different (writes POSIX-format
        archives by default, not GNU-format).  The command lines are
        sufficiently similar that most users should have no problems
        with the transition.  However, people who rely on peculiar
        options or capabilities of gtar may have to look to ports.</p>
    </body>
  </project>
  <project>
    <title>Network interface naming changes</title>
    
    <contact>
      <person>
        <name>
          <given>Brooks</given>
          
          <common>Davis</common>
        </name>
        
        <email>brooks@FreeBSD.org</email>
      </person>
    </contact>
    
    <links>
    </links>
    
    <body>
      <p>The first actual feature related to the if_xname conversion was
        committed in early February.  Network interfaces can now be
        renamed with "ifconfig &lt;if&gt; name &lt;newname&gt;".</p>
      
      <p>Work is slowly progressing on a new network interface cloning API
        to enable interesting cloners like auto-configurating vlans. 
        This work is taking place in the perforce repository under:
        //depot/user/brooks/xname/...</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>After a slow time at the end of last year due to a disk crash,
        the project is moving along rapidly. The loader is fully
        functional with Forth support. Syscons has been integrated.
        New Powerbook models are supported. Work is starting on a
        G5 port.</p>
      
      <p>There's still lots to do, so as usual volunteers are most
        welcome.</p>
    </body>
  </project>
  <project>
    <title>The FreeBSD Simplified Chinese Project</title>
    <contact>
      <person>
        <name>
          <given>Dong</given>
          <common>LI</common>
        </name>
        <email>ld@FreeBSD.org.cn</email>
      </person>
      <person>
        <name>
          <given>Xin</given>
          <common>LI</common>
        </name>
        <email>delphij@frontfree.net</email>
      </person>
    </contact>
    <links>
      <url href="http://www.FreeBSD.org.cn">The FreeBSD Simplified
      Chinese Project (In Simplified Chinese)</url>
      <url href="http://www.FreeBSD.org.cn/snap/zh_CN/">Translated
      Website Snapshot</url>
      <url href="http://www.FreeBSD.org.cn/snap/doc/zh_CN.GB2312/books/handbook/">Translated Handbook Snapshot</url>
    </links>
    <body>
      <p>The project is a joint effort of volunteers, which focus in
        the internationalization and localization of the FreeBSD
        Operating System and applications running on FreeBSD. All of the
        work resulted in this project will be contributed back to the
        FreeBSD project.</p>
      <p>Thanks to many volunteers' help, by this time of writing, we
        have finished more than 60% of the translation of the FreeBSD
        Handbook. We plan to submit a preliminary translation of the
        FreeBSD website as well as the FreeBSD Handbook when most part of
        them were finished, which is expected to happen in a couple of
        months. The snapshot of the documentation translation effort
        could be accessed through the URL listed above.</p>
      <p>The project also supported individual efforts on porting
        applications (especially software that supports Simplified
        and/or Traditional Chinese) to FreeBSD. We are also doing some
        research on making FreeBSD kernel and base system more
        i18n-aware.</p>
    </body>
  </project>
  <project>
    <title>Verify source reachability option for ipfw2</title>
    <contact>
      <person>
        <name>
          <given>Andre</given>
          <common>Oppermann</common>
        </name>
        <email>andre@FreeBSD.org</email>
      </person>
    </contact>
    <links>
      <url href="http://www.nrg4u.com/freebsd/ipfw_versrcreach.diff"/>
    </links>
    <body>
      <p>The verify source reachability option for ipfw2 checks if the
        source IP address of a packet entering the machine is reachable
        at all.  Thus if we can't send a packet back because we don't
        have a route back we don't have to forward it because two way
        communication isn't possible anyway.  It is more than likely
        that such a packet is spoofed.  This option is almost the same as
        what is known on Cisco IOS as "ip verify unicast source
        reachable-via [any|ifn]".  Using this option only makes sense
        when you don't have a default route which naturally always
        matches.  So this is useful for machines acting as routers with
        a default-free view of the entire Internet as common when running
        a BGP daemon (Zebra/Quagga or OpenBSD bgpd).</p>
      <p>One useful way of enabling it globally on a router looks like
        this: ipfw add xxxx deny ip from any to any not versrcreach or for
        an individual interface only: ipfw add xxxx deny ip from any to
        any not versrcreach recv fxp0</p>
    </body>
  </project>
  
  <project>
    <title>Move ARP out of routing table</title>
    <contact>
      <person>
        <name>
          <given>Andre</given>
          <common>Oppermann</common>
        </name>
        <email>andre@FreeBSD.org</email>
      </person>
    </contact>
    <body>
      <p>The ARP IP address to MAC address mapping does not belong into
        the routing table (FIB) as it is currently done.  This will move
        it to its own hash based structure which will be instantiated
        per each 802.1 broadcast domain.  With this change it is possible
        to have more than one interface in the same IP subnet and layer 2
        broadcast domain.  The ARP handling and the routing table will be
        quite a bit simplified afterwards.  As an additional benefit full
        MAC address based accosting will be provided.  Work on this
        project is already in progress.</p>
    </body>
  </project>
  <project>
    <title>Automatic sizing of TCP send buffers</title>
    <contact>
      <person>
        <name>
          <given>Andre</given>
          <common>Oppermann</common>
        </name>
        <email>andre@FreeBSD.org</email>
      </person>
    </contact>
    <body>
      <p>The current TCP send and receive buffers are static and set to a
        conservative value to preserve kernel memory.  This is sub-optimal
        for connections with a high bandwidth*delay product because the
        size of the TCP send buffer determines how big the send window
        can get.  For high bandwidth trans-continental links this seriously
        limits the maximum transfer speed per TCP connection.  For example
        a 170ms RTT and a 32kB send buffer limit the speed to approximately
        1.5Mbit per second even thought you might have a 10Mbit pipe.</p>
      <p>This project makes the TCP send buffer to automatically adapt to
        the optimal buffer size for maximal link usage.  In the case
        above this would be a buffer of approximately 220kB.  The main
        challenge is to have a stable and reliable measurement of the link
        parameters and manage the kernel memory properly and in a fair way.
        We don't want to have a few connections to monopolize all available
        socket buffer space and many edge cases have to be considered.  The
        first implementation will be tuned conservatively but even that
        will provide significantly better performance than the static
        buffers currently.  Work on this project is already in
        progress.</p>
    </body>
  </project>
  
  <project>
    <title>Testbed for testing and qualification of TCP performance</title>
    <contact>
      <person>
        <name>
          <given>Andre</given>
          <common>Oppermann</common>
        </name>
        <email>andre@FreeBSD.org</email>
      </person>
    </contact>
    <body>
      <p>The TCP performance test and qualification testbed is an automated
        environment that simulates various common and uncommon end-to-end
        network and link characteristics such as delay, bandwidth
        limitations, congestion, packet drops, packet corruption and out
        of order arrival.  The testbed automatically steps through all
        link types and tests various TCP optimizations and parameter
        adjustments.  In the end all data is graphically arranged and
        compared against standard behaviour and each other to judge the
        positive or negative effects of the modifications.  Work on this
        project has just started and is based on FreeBSDs dummynet.</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://portsmon.firepipe.net/index.html">
      FreeBSD ports monitoring system</url>
    </links>
    
    <body>
      <p>Thanks to the loan of a box by Will Andrews, the system has
        been moved into production.  The previous installation
        at lonesome.com now refers you to the new system.  As part of
        the installation, a preliminary
        <a href="http://portsmon.firepipe.net/faq.html">FAQ</a> was
        added.</p>
      <p>The database is updated once per hour.</p>
      <p>New reports available include ones about ports marked DEPRECATED,
        since that function has now been incorporated into bsd.port.mk.
       (The author hopes that this will allow the port deprecation process
       to be much more visible to the general FreeBSD user community.)  In
       addition, a report for ports marked FORBIDDEN was added (the code
       was essentially the same).</p>
      <p>The next topic of interest is to try to identify ports which are
        slave ports because the status of these ports is not currently
        being updated automatically.  This problem also affects
        FreshPorts.  PR ports/63683 is an attempt to address this problem.
        Also, preliminary work has been done on creating some graphs and
        charts for various statistics, and in creating a tool to browse
        port dependencies for the entire ports tree.</p>
      <p>Some general observations about the trends in ports PRs can be
        made:
        <ul>
          <li>In the past 6 months, the amount of time to get ports PRs
            committed has dropped dramatically.  (This is especially
            true of PRs for new ports.)</li>
          <li>The queue of PRs for existing ports that are unmaintained
            has similarly been trimmed.  Both of these two items are due
            in large part to a few very active committers (how do they
            ever get their "real" work done?)  Thanks, guys, you know who
            you are.</li>
          <li>There is still a fairly high number of PRs (~400/~750) which
            apply to existing ports, and have been assigned to a FreeBSD
            committer.  This represents around 370 individual ports. We
            seem to have a much harder time getting these numbers to go
            down; basically, we just hold our own most weeks.  This is
            somewhat disappointing.</li>
          <li>The number of ports marked BROKEN has jumped dramatically,
            currently standing at over 250 (for i386-current).  This
            represents less a sudden problem as it does Kris' effort to
            bring existing brokenness to people's attention -- thus, a
            much larger percentage of ports with build errors are now
            labeled as BROKEN.</li>
          <li>Approximately two-thirds of the port build errors are still
            due to compilation problems, primarily from the gcc3.3 import.
            Another 10% fail to install correctly.  The reasons for the
            others are more varied.</li>
        </ul>
      </p>
    </body>
  </project>
  <project>
    <title>FreeSBIE</title>
    <contact>
      <person>
        <name>
          <given>FreeSBIE</given>
          <common>Staff</common>
        </name>
        <email>staff@FreeSBIE.org</email>
      </person>
    </contact>
    <links>
      <url href="http://www.freesbie.org">FreeSBIE Home</url>
      <url href="mailto:freesbie@gufi.org">FreeSBIE Mailing
      List</url>
      <url href="http://www.freesbie.org/?section=mirror-en">FreeSBIE
      Mirror List</url>
    </links>
    <body>
      <p>The FreeSBIE Project aims to develop a set of scripts that allow
        anyone to create their own FreeBSD Bootable Cdrom, with their own
        set of installed packages.  The Project releases an ISO builded
        with FreeSBIE scripts, to show what they can do. On Sunday 29
        February 2004, FreeSBIE 1.0 was released and it had a great
        success, as there were post on Slashdot.org, OSnews, DaemonNews
        and BSDForums. Thanks to the huge amount of feedback they got,
        FreeSBIE Developers are now developing new features such as
        support for archs different from i386. Website redesign is on the
        way too.</p>
    </body>
  </project>
  <project>
    <title>kgi4BSD</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>Move to Perforce is done. I spent some time on building a
        common compilation tree with Linux: until now drivers were
        build in a FreeBSD makefile tree, not compatible with Linux.</p>
      
      <p>The next priorities are ANSI support and keymaps in the
        KGC Kernel Graphic Console system.</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">
      Home page.</url>
    </links>
    
    <body>
      <p>Work on the PMAP overhaul has been put into gear. A lot of issues
        will be addressed, including support for sparse physical memory
        and of course SMP. Performance will be addressed to the extend
        possible, but functionality has priority. The redesign will lay
        the foundation for NUMA support where possible. An example of this
        is limiting TLB shootdowns to processors that actually have or had
        TLBs belonging to the PMAP loaded. Of course, without NUMA
        hardware the implementation of NUMA support is quite limited.</p>
    </body>
  </project>
  <project>
    <title>FreeBSD Package Grid</title>
    
    <contact>
      <person>
        <name>
          <given>Kris</given>
          <common>Kennaway</common>
        </name>
        <email>kris@FreeBSD.org</email>
      </person>
    </contact>
    
    <body>
      
      <p>Distributed package builds are currently done using a set of
        home-grown shell scripts for managing, scheduling and
        dispatching of package builds on the client machines.  This has
        been sufficient for our needs in the past, but has a number of
        significant shortcomings that limit future growth.  I am
        rewriting the package build scripts to work on top of Sun
        GridEngine (ports/sysutils/sge), as a client application of a
        "FreeBSD package grid".  Some of the design goals for the new
        system are:</p>
      
      <ul>
        <li>Better robustness against machine failure, and more efficient
          scheduling of build jobs</li>
        <li>Support for remote build machines, to make better use of machine
          resources and clusters that are not on the same LAN as the
          build master</li>
        <li>Ability for other committers to submit port build jobs to the
          system, for testing of changes, new ports, etc.</li>
      </ul>
      
    </body>
  </project>
  <project>
    <title>vinum + GEOM</title>
    <contact>
      <person>
        <name>
          <given>Lukas</given>
          <common>Ertl</common>
        </name>
        <email>le@FreeBSD.org</email>
      </person>
    </contact>
    
    <links>
      <url href="http://mailbox.univie.ac.at/~le/geom_vinum.tar.gz" />
    </links>
    
    <body>
      <p>The "geomification" of vinum has made some progress.  I now have
        all basic setups working (concatenated plexes, striped plexes,
        RAID5 plexes, and RAID1), but I still have to implement correct
        error handling and status change handling.</p> 
      <p>Still missing is a userland tool, so currently you still have to
        use "old-style" vinum to configure your setup.</p>
    </body>
  </project>
  <project>
    <title>NanoBSD</title>
    
    <contact>
      <person>
        <name>
          <given>Poul-Henning</given>
          <common>Kamp</common>
        </name>
        <email>phk@FreeBSD.org</email>
      </person>
    </contact>
    
    <body>
      <p>NanoBSD, src/tools/tools/nanobsd, is a tool for stuffing FreeBSD
        onto small disk media (like CompactFlash) for embedded
        applications.  The disk image is built with three partitions, two
        for software images and one for configuration files.  Having two
        software partitions means that new software can be uploaded to the
        non-active partition while running off the active partition.</p>
      <p> The first really public version has been committed and many 
        suggestions and offers of patches have started pouring in.</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/" />
      <url href="http://www.benzedrine.cx/pf.html">PF homepage</url>
      <url href="http://openbsd.org/faq/pf/index.html">PF FAQ</url>
      <url href="http://www.rofug.ro/projects/freebsd-altq/">ALTQ</url>
    </links>
    
    <body>
      <p>The sources were imported from OpenBSD 3.4R and patched with
        diffs obtained from the port. Since March the 8th it is linked
        to the build and install. There is some more work to be done in
        order make pf a home inside the tree, but the biggest hunk of
        work was lifted during the past two month.</p>
      <p>OpenBSD 3.5 is scheduled for early May, so we might see an update
        before 5.3R. Work towards integration of the - often requested
        - ALTQ framework is in progress also, though it is not yet clear
        how well it goes along with the ongoing work towards a giant free
        net stack.</p>
    </body>
  </project>
  <project>
    <title>FreeBSD/arm Status Report</title>
    <contact>
      <person>
        <name>
          <given>Olivier</given>
          <common>Houchard</common>
        </name>
        <email>cognet@FreeBSD.org</email>
      </person>
    </contact>
    
    <body>
      <p>Development goes reasonably fast, right now it boots single user.
        It is still very simics-centric, and it deserves a huge cleanup
        and a few bug fixes, but there's already a decent amount of code
        to work with, mostly taken from NetBSD. I now plan to work on real
        hardware support (as soon as I can get some), to get the missing
        userland bits (mainly rtld and the pthread libs) so that I can
        build a full world.</p>
    </body>
  </project>
  <project>
    <title>SGI XFS port for FreeBSD</title>
    <contact>
      <person>
        <name>
          <given>Alexander</given>
          <common>Kabaev</common>
        </name>
        <email>kan@FreeBSD.org</email>
      </person>
      <person>
        <name>
          <given>Russell</given>
          <common>Cattelan</common>
        </name>
        <email>cattelan@thebarn.com</email>
      </person>
    </contact>
    
    <body>
      <p>Not much has changed since last report was submitted. The
        read-only access XFS volumes is quite stable now. The work is
        underway to rewrite xfs_buf layer to minimize local changes
        intrusiveness. Initial attempt to make XFS code to compile and
        run on amd64 is in progress too.</p>
      <p>We really need a care-taker for our userland tools.</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>If nothing bad happened, the icc patches got committed around
        the date of the deadline for submissions of this report. Please
        search the archives of -current and/or cvs-all for more
        information.</p>
       
      <p>The next steps in this project are to
        <ul>
          <li>fix the kernel to also run without problems when compiled
            with icc v8</li>
          <li>fix the kernel if some problems surface after more people
            give it a try</li>
          <li>get some ports to compile with icc</li>
        </ul>
      </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>
    
    <body>
      <p>Not much to report. Bluetooth Service Discovery Procotol daemon
        sdpd was integrated with existing Bluetooth utilities. From now
        on users should not use GNU sdpd (Linux BlueZ port).</p>
      <p>Bluetooth HID profile implementation is almost complete. Thanks
        to Matt Peterson &lt; matt at peterson dot org &gt; for giving me
        Bluetooth keyboard and mouse for development.</p>
    </body>
  </project>
  <project>
    <title>FreeBSD GNOME Project Report</title>
    
    <contact>
      <person>
        <name>
          <given>FreeBSD</given>
          <common>GNOME Team</common>
        </name>
        <email>gnome@FreeBSD.org</email>
      </person>
    </contact>
    
    <links>
      <url href="http://www.FreeBSD.org/gnome/">FreeBSD GNOME Project
      Site.</url>
    </links>
    
    <body>
      <p>It has been a year since our last status report, but we
        haven't slowed down. Since the last report, Alexander
        Nedotsukov (bland) and Pav Lucistnik (pav) have joined the
        FreeBSD GNOME team. GNOME 2.4 was released back in September
        2003, followed by 2.4.1 and 2.4.2. We are actively working on
        getting GNOME 2.6.0 out the door at the end of March. GNOME 2.6
        Beta releases can be obtained via the project URL above.</p>
      
      <p>To help make GNOME 2.6.0 our best release to date, we have
        created a script to automate the upgrade from GNOME 2.4. We
        also have a new GNOME
        <a href="http://www.marcuscom.com/tinderbox/">package build
        server</a>
        that builds and serves i386 packages for all supported FreeBSD
        releases. We plan on having the GNOME 2.6.0 packages available
        the moment 2.6.0 hits the ports tree.</p>
      
      <p>Included in the release of GNOME 2.6 is GTK+ 2.4, the next
        installment in the GTK+ 2 series. Because GTK+ 2 has become
        very stable over the past few years, the FreeBSD GNOME Team is
        pushing for GTK+ 2 support to be included by default in all
        applications that support it. This has already been done with
        Mozilla, Firefox, and Thunderbird. A complete GNOME Desktop and
        application environment can already be built using only GTK+ 2.
        The ultimate goal is to phase GTK+ 1 out of the ports tree.</p>
    </body>
  </project>
  <project>
    <title>Network Stack Locking</title>
    
    <contact>
      <person>
        <name>
          <given>Sam</given>
          <common>Leffler</common>
        </name>
        <email>sam@FreeBSD.org</email>
      </person>
      
      <person>
        <name>
          <given>Robert</given>
          <common>Watson</common>
        </name>
        <email>rwatson@FreeBSD.org</email>
      </person>
    </contact>
    
    <links>
    </links>
    
    <body>
      <p>This project is aimed at converting the FreeBSD network stack from
        running under the single Giant kernel lock to permitting it to
        run in a fully parallel manner on multiple CPUs (i.e., a fully
        threaded network stack).  This will improve performance/latency
        through reentrancy and preemption on single-processor machines,
        and also on multi-processor machines by permitting real
        parallelism in the processing of network traffic.  As of FreeBSD
        5.2, it was possible to run low level network functions, as well
        as the IP filtering and forwarding plane, without the Giant lock,
        as well as "process to completion" in the interrupt handler.</p>
      
      <p>Work continues to improve the maturity and completeness of
        the locking (and performance) of the network stack for 5.3. The
        network stack locking development branch has been updated to the
        latest CVS HEAD, tracking a variety of FreeBSD changes, including
        tracking and driving changes in the interface and device cloning
        APIs, push-down and fixes to locking in the Berkeley Packet
        Filter, consistency improvements in allocation flags for network
        objects, diagnosis of excessive acquisition of Giant in various
        system callouts and timeouts, removal of Giant from several
        system callouts, "const"-ification of a number of global
        variables in the network stack (IPv4, IPv6, elsewhere) as part of
        ananalysis of locking requirements, fine-grain locking of a
        number of pseudo-interfaces (disc, loopback, faith, stf, gif, tap,
        tun), IP encapsulation and tunneling, initial review and locking
        of parts of PPP and SLIP, experimentation with PCB assertions on
        IPv6, additional socket locking assertions, graphing of the FreeBSD
        sockets layer to support locking analysis, merging of theMT_TAG to
        m_tag conversion to improve the ability to queue packets, moving
        of the debug.mpsafenet tunable to controlling Giant over the
        forwarding plane to Giant over the entire stack("dual-mode" to
        support non-MPSAFE protocols), adaption of existing network lock
        assertions to also assert Giant when running non-MPSAFE, analysis
        of high cost of select() locking, improved locking and
        synchronization annotations, TCP callouts run MPSAFE, logtimeout()
        runs MPSAFE, uma_timeout() runs MPSAFE, callout sampling
        instrumentation, loadav() runs MPSAFE, AppleTalk locking begun:
        AARP locked down and DDP analysis, rawcb list locked, locking
        analysis of mrouter and IP ID code, IGMP locked, IPv6 analysis
        begun, IPX/SPX analysis begun, PPP timeouts converted to callouts,
        Netgraph analysis begun.  Many of these changes have not yet been
        merged to the main FreeBSDtree, but this is a work in progress.</p>
      
      <p>In related work on Pipe IPC (not quite network stack locking),
        substantial time was invested in diagnosing an increase in the
        cost of pipe allocation since FreeBSD 4.x, as well as coalescing
        the several allocations needed to create a pipe, as well as moving
        to slab allocation so as to amortize the cost of pipe
        initialization.  Future work here will include caching the VM
        structures supporting pipe buffers.</p>
      
      <p>Recent contributors include Robert Watson, Sam Leffler, MaxLaier,
        Maurycy Pawlowski-Wieronski, Brooks Davis, and many others who are
        omitted here only by accident.</p>
    </body>
  </project>
</report>