Add an initial page for the much rumored projects and ideas list for volunteers
and developers that are looking for interesting projects to evaluate and work on. Original idea and work by: netchild Reviewed by: brueffer, simon, Niclas Zeising lothrandilATn00bDOTapagnuDOTse
This commit is contained in:
Joel Dahl
parent
cac0c74506
commit
0fe8b90919
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/www/; revision=26533
4 changed files with 880 additions and 2 deletions
en/projects
|
|
@ -1,4 +1,4 @@
|
|||
# $FreeBSD: www/en/projects/Makefile,v 1.22 2005/04/18 11:47:07 phk Exp $
|
||||
# $FreeBSD: www/en/projects/Makefile,v 1.23 2005/06/01 20:59:16 murray Exp $
|
||||
|
||||
.if exists(../Makefile.conf)
|
||||
.include "../Makefile.conf"
|
||||
|
|
@ -14,6 +14,6 @@ DOCS+= summerofcode.sgml
|
|||
|
||||
INDEXLINK= projects.html
|
||||
|
||||
SUBDIR= acpi busdma c99 dingo gnats4 mips bigdisk netperf nanobsd
|
||||
SUBDIR= acpi busdma c99 dingo gnats4 ideas mips bigdisk netperf nanobsd
|
||||
|
||||
.include "${WEB_PREFIX}/share/mk/web.site.mk"
|
||||
|
|
|
|||
17
en/projects/ideas/Makefile
Normal file
17
en/projects/ideas/Makefile
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
# FreeBSD list of projects and ideas for volunteers
|
||||
#
|
||||
# $FreeBSD$
|
||||
|
||||
MAINTAINER= joel
|
||||
|
||||
.if exists(../Makefile.conf)
|
||||
.include "../Makefile.conf"
|
||||
.endif
|
||||
.if exists(../Makefile.inc)
|
||||
.include "../Makefile.inc"
|
||||
.endif
|
||||
|
||||
DOCS= index.sgml
|
||||
DATA= style.css
|
||||
|
||||
.include "${WEB_PREFIX}/share/mk/web.site.mk"
|
||||
823
en/projects/ideas/index.sgml
Normal file
823
en/projects/ideas/index.sgml
Normal file
|
|
@ -0,0 +1,823 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" [
|
||||
<!ENTITY base CDATA "../..">
|
||||
<!ENTITY date "$FreeBSD$">
|
||||
<!ENTITY title "FreeBSD list of projects and ideas for volunteers">
|
||||
<!ENTITY % navincludes SYSTEM "../../includes.navdocs.sgml"> %navincludes;
|
||||
<!ENTITY % includes SYSTEM "../../includes.sgml"> %includes;
|
||||
<!ENTITY % developers SYSTEM "../../developers.sgml"> %developers;
|
||||
]>
|
||||
|
||||
<html>
|
||||
&header;
|
||||
|
||||
<h2>Introduction</h2>
|
||||
|
||||
<p>The FreeBSD project has hundreds of active developers spread all over the
|
||||
world, and many of them have their own parts of the source-tree that they
|
||||
work on. However, there are always a lot of new interesting projects and
|
||||
ideas that needs to be investigated and evaluated, and this is where the
|
||||
FreeBSD project relies on heroic efforts from volunteers. The following
|
||||
list of possible projects is in no way complete, but it should serve as a
|
||||
nice starting point for volunteers who would like to become committers in
|
||||
the future.</p>
|
||||
|
||||
<p>Please note that we cannot guarantee that your work will be included in the
|
||||
FreeBSD source tree. This is because people tend to disagree about specifics
|
||||
in the implementation of new features or functionality. However, if you can
|
||||
find a developer who is interested in your work, and you can get him or her
|
||||
to review it, then you are pretty far on your way to get your code into the
|
||||
FreeBSD source tree.</p>
|
||||
|
||||
<hr>
|
||||
|
||||
<h2>Project ideas</h2>
|
||||
|
||||
<h3>File System</h3>
|
||||
<ul>
|
||||
<li><a href="#p-autofs">Autofs</a></li>
|
||||
<li><a href="#p-magicsymlinks">Implement Magic Symlinks</a></li>
|
||||
<li><a href="#p-mdfs">Fix mdfs lockups when using non-sync operation
|
||||
modes</a></li>
|
||||
<!--<li><a href="#p-logicalvolume">Logical Volume Manager</a></li>-->
|
||||
</ul>
|
||||
|
||||
<h3>Kernel</h3>
|
||||
<ul>
|
||||
<li><a href="#p-sxsemantics">Usable lock implementation with
|
||||
SX-semantics</a></li>
|
||||
<li><a href="#p-docsysctl">Document as many sysctls as possible</a></li>
|
||||
<li><a href="#p-docsound">Document the sound subsystem</a></li>
|
||||
<li><a href="#p-sync4front">Syncing with the 4Front Technologies OSS v4
|
||||
API</a></li>
|
||||
<li><a href="#p-implement4front">Implement necessary kernel interface for
|
||||
4Front Technologies ALSA to OSS wrapper (SALSA)</a></li>
|
||||
<li><a href="#p-soundlocking">Improve locking of the sound
|
||||
system</a></li>
|
||||
<li><a href="#p-hda">Add High Definition Audio (HDA) support to our sound
|
||||
system</a></li>
|
||||
<li><a href="#p-geninput">Implement a generic input device layer</a></li>
|
||||
<li><a href="#p-camlocking">Add locking to the CAM layer</a></li>
|
||||
<li><a href="#p-iscsi">Implement iSCSI</a></li>
|
||||
<li><a href="#p-processcheck">Port DragonFly's process
|
||||
checkpointing</a></li>
|
||||
<li><a href="#p-memcpy">Evaluate and perhaps port DragonFly's optimized
|
||||
memcpy/bcopy/bzero support subsystem (this includes an FPU subsystem
|
||||
overhaul)</a></li>
|
||||
<li><a href="#p-bootcode">Evaluate and perhaps sync FreeBSD i386 boot code
|
||||
with DragonFly's boot code</a></li>
|
||||
<li><a href="#p-cpuusage">Fix the CPU usage display in top for threaded
|
||||
processes</a></li>
|
||||
<li><a href="#p-pcihotplug">Implement PCI-Hotplug support</a></li>
|
||||
<li><a href="#p-dtrace">Implement something similar to Solaris'
|
||||
DTrace</a></li>
|
||||
<li><a href="#p-amd64linux">Add amd64 native support to the
|
||||
Linuxulator</a></li>
|
||||
<li><a href="#p-updatelinux">Update the Linuxulator</a></li>
|
||||
<li><a href="#p-assembler">Annotate every assembler file [*.[sS]] with
|
||||
dwarf2 call frame information</a></li>
|
||||
<li><a href="#p-suspend">Suspend to disk</a></li>
|
||||
</ul>
|
||||
|
||||
<h3>Networking</h3>
|
||||
<ul>
|
||||
<li><a href="#p-zeroconf">Add zeroconf (Rendezvous/Bonjour) support to
|
||||
FreeBSD</a></li>
|
||||
<!--<li><a href="#p-isdn4bsd">Modernize ISDN4BSD</a></li>-->
|
||||
<li><a href="#p-networkdisk">Network Disk Device</a></li>
|
||||
<li><a href="#p-nfslockdsemantics">NFS Lockd (improve semantics)</a></li>
|
||||
<li><a href="#p-nfslockdkernel">NFS Lockd (kernel implementation)</a></li>
|
||||
<li><a href="#p-web100">Port Web100 to FreeBSD</a></li>
|
||||
</ul>
|
||||
|
||||
<h3>Security</h3>
|
||||
<ul>
|
||||
<li><a href="#p-securemines">SecureMines</a></li>
|
||||
</ul>
|
||||
|
||||
<h3>Userland / Installation Tools</h3>
|
||||
<ul>
|
||||
<li><a href="#p-sysinstall">Small sysinstall renovation</a></li>
|
||||
<li><a href="#p-pxeinstaller">Bundled PXE Installer</a></li>
|
||||
<li><a href="#p-regression">Improve our regression testing system</a></li>
|
||||
<li><a href="#p-performancetracking">Tracking performance over time</a></li>
|
||||
</ul>
|
||||
|
||||
<h3>Additional Information</h3>
|
||||
<ul>
|
||||
<li><a href="#p-projects">Projects at FreeBSD.org</a></li>
|
||||
<li><a href="#p-tc">Technical contacts</a></li>
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-autofs"></a>
|
||||
<h2>Autofs</h2>
|
||||
<p><strong>Technical contact</strong>: <a
|
||||
href="mailto:alfred@FreeBSD.org">&a.alfred;</a></p>
|
||||
<p>Create the autofs file system from a specification. Most of this work is
|
||||
done, however, kernel transport and interaction with the "amd" automounter
|
||||
needs to be completed.</p>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Knowledge of file systems and network file systems.</li>
|
||||
<li>Good knowledge of C.</li>
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-magicsymlinks"></a>
|
||||
<h2>Implement Magic Symlinks</h2>
|
||||
<p><strong>Technical contact</strong>: <a
|
||||
href="mailto:jwd@FreeBSD.org">&a.jwd;</a></p>
|
||||
<p><strong>Patches</strong>: <a
|
||||
href="http://people.FreeBSD.org/~jwd/magiclinks.tgz">http://people.FreeBSD.org/~jwd/magiclinks.tgz</a></p>
|
||||
<p>Experimental patches exist against 4-STABLE, though the DragonFly
|
||||
implementation using the setvar utility should be examined (interesting
|
||||
files in the DragonFly CVS: sys/kern/init_sysent.c, sys/kern/kern_varsym.c,
|
||||
sys/kern/syscalls.c, sys/kern/syscalls.master, sys/kern/vfs_lookup.c,
|
||||
sys/sys/syscall-hide.h, sys/sys/syscall.h, sys/sys/syscall.mk,
|
||||
sys/sys/sysproto.h, sys/sys/sysunion.h, bin/varsym/varsym.1,
|
||||
bin/varsym/varsym.c).</p>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Ability to read and understand foreign C code.</li>
|
||||
<li>Ability to write C code.</li>
|
||||
<li>Some file system knowledge.</li>
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-mdfs"></a>
|
||||
<h2>Fix mdfs lockups when using non-sync operation modes</h2>
|
||||
<p><a href="&cgibase;/cvsweb.cgi/sys/dev/md/md.c#rev1.115">Rev. 1.115 of
|
||||
md.c</a> has a discussion of the problem.</p>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Ability to read and understand foreign C code.</li>
|
||||
<li>Ability to write C code.</li>
|
||||
<li>Knowledge of the VFS and VMA subsystems.</li>
|
||||
</ul><!-- netchild -->
|
||||
|
||||
<hr>
|
||||
|
||||
<!--
|
||||
<a name="p-logicalvolume"></a>
|
||||
<h2>Logical Volume Manager</h2>
|
||||
<p><strong>Mentor</strong>: <a href="mailto:none">none</a></p>
|
||||
<p>none</p>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>none</li>
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
!-->
|
||||
|
||||
<a name="p-sxsemantics"></a>
|
||||
<h2>Usable lock implementation with SX-semantics</h2>
|
||||
<p><strong>Technical contact</strong>: <a
|
||||
href="mailto:mlaier@FreeBSD.org">&a.mlaier;</a></p>
|
||||
<p>The current sx(9) implementation has several problems that make it unusable
|
||||
in many areas: Might sleep (cv_wait) on the shared lock acquisition,
|
||||
implicit, hardcoded priority order without starvation protection, ... There
|
||||
are several handrolled lock implementations with SX-semantics in the tree
|
||||
already that solve some of the problems in their specific domain: MAC, pfil,
|
||||
ipfw, if_bridge, ...</p>
|
||||
<ul>
|
||||
<li>Review existing uses of non-standard sx-locks.</li>
|
||||
<li>Design an API usable to replace most/all of the handrolled hacks or find
|
||||
an existing API to do the same.</li>
|
||||
<li>Write the actual code.</li>
|
||||
</ul>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>C knowledge.</li>
|
||||
<li>Knowledge about shared/exclusive locking in SMP systems.</li>
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-docsysctl"></a>
|
||||
<h2>Document as many sysctls as possible</h2>
|
||||
<p><strong>Contact</strong>: <a
|
||||
href="mailto:brd@FreeBSD.org">&a.brd;</a></p>
|
||||
<p>The sysctl(8) utility retrieves kernel states and allows processes with
|
||||
appropriate privilege to change kernel states. On request it is able to
|
||||
display description lines which document the kernel state. Unfortunately
|
||||
not every sysctl is documented. This task is possible to share with other
|
||||
volunteers.</p>
|
||||
<ul>
|
||||
<li>Find every undocumented sysctl in the kernel.</li>
|
||||
<li>Try to determine what this sysctl is for and document it.</li>
|
||||
</ul>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Ability to read and understand foreign C code.</li>
|
||||
</ul><!-- Glenn Dawson <glenn@antimatter.net> -->
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-docsound"></a>
|
||||
<h2>Document the sound subsystem</h2>
|
||||
<p><strong>Technical contacts</strong>: <a
|
||||
href="mailto:netchild@FreeBSD.org">&a.netchild;</a>, <a
|
||||
href="mailto:ariff@FreeBSD.org">&a.ariff;</a></p>
|
||||
<p><!-- Description needed --></p>
|
||||
<ul>
|
||||
<li>Add sound subsystem related section 9 manual pages, so far no sound
|
||||
subsystem related manual pages exists.</li>
|
||||
<li>Add an example driver in share/examples which allows to write a new
|
||||
driver. For this purpose the example driver should contain enough
|
||||
documentation as comments and/or pointers to documentation in man-section
|
||||
9. This work can be based upon <a
|
||||
href="http://people.FreeBSD.org/~cg/template.c">this template.</a></li>
|
||||
<li>Rewrite the sound subsystem chapter in the FreeBSD Architecture Handbook.
|
||||
The rewrite should contain an overview of the available parts in the sound
|
||||
subsystem and how they interact (data flow, dependencies, ...) and fit
|
||||
together. Additionally it should contain links to already available
|
||||
documentation (official standards, section 9 manual pages, ...).</li>
|
||||
</ul>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Ability to read and understand foreign C code.</li>
|
||||
<li>Documentation writing skills.</li>
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-sync4front"></a>
|
||||
<h2>Syncing with the 4Front Technologies OSS v4 API</h2>
|
||||
<p><strong>Technical contact</strong>: <a
|
||||
href="mailto:netchild@FreeBSD.org">&a.netchild;</a></p>
|
||||
<p><strong>URL</strong>: <a href="http://www.opensound.com/">4Front
|
||||
Technologies</a></p>
|
||||
<p>4Front Technologies will go live with an improved OSS API in the near future
|
||||
and we are discussing syncing with this API at the freebsd-multimedia mailing
|
||||
list. 4Front Technologies offered assistance. A volunteer would have
|
||||
to:</p>
|
||||
<ul>
|
||||
<li>Add the necessary interfaces.</li>
|
||||
<li>Add appropriate code to the sound subsystem/drivers where possible.</li>
|
||||
<li>Document the work (manual pages, maybe sound subsystem chapter in the
|
||||
FreeBSD Architecture Handbook, maybe extending the example driver). This
|
||||
part overlaps with the sound subsystem documentation project. Maybe
|
||||
4Front is willing to donate parts of their documentation. Coordination
|
||||
regarding this is required.</li>
|
||||
<li>Use the improved API in our userland programs where it is
|
||||
beneficial.</li>
|
||||
</ul>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Ability to read and understand foreign C code.</li>
|
||||
<li>Ability to write C code.</li>
|
||||
<li>At least one supported sound card.</li>
|
||||
</ul><!-- netchild -->
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-implement4front"></a>
|
||||
<h2>Implement necessary kernel interface for 4Front Technologies ALSA to OSS
|
||||
wrapper (SALSA)</h2>
|
||||
<p><strong>Technical contact</strong>: <a
|
||||
href="mailto:netchild@FreeBSD.org">&a.netchild;</a></p>
|
||||
<p><strong>URL</strong>: <a href="http://www.opensound.com/">4Front
|
||||
Technologies</a>, <a
|
||||
href="http://www.4front-tech.com/forum/viewtopic.php?t=296">SALSA</a></p>
|
||||
<p><!-- Description needed --></p>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Ability to read and understand foreign C code.</li>
|
||||
<li>Ability to write C code.</li>
|
||||
<li>At least one supported sound card.</li>
|
||||
</ul><!-- netchild -->
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-soundlocking"></a>
|
||||
<h2>Improve locking of the sound system</h2>
|
||||
<p><strong>Technical contact</strong>: <a
|
||||
href="mailto:ariff@FreeBSD.org">&a.ariff;</a></p>
|
||||
<p><!-- Description needed --></p>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Ability to read and understand foreign C code.</li>
|
||||
<li>Ability to write C code.</li>
|
||||
<li>A good understanding of the FreeBSD locking methods.</li>
|
||||
</ul><!-- netchild -->
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-hda"></a>
|
||||
<h2>Add High Definition Audio (HDA) support to our sound system</h2>
|
||||
<p><strong>Technical contact</strong>: <a
|
||||
href="mailto:ariff@FreeBSD.org">&a.ariff;</a></p>
|
||||
<p><!-- Description needed --></p>
|
||||
<p><strong>URL</strong>: <a href="http://www.intel.com/standards/hdaudio/">HDA
|
||||
Specification</a></p>
|
||||
<ul>
|
||||
<li>Have a look at the specification.</li>
|
||||
<li>Implement HDA support.</li>
|
||||
</ul>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Ability to read and understand foreign C code.</li>
|
||||
<li>Ability to write C code.</li>
|
||||
<li>HDA sound card.</li>
|
||||
</ul><!-- netchild -->
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-geninput"></a>
|
||||
<h2>Implement a generic input device layer</h2>
|
||||
<p><strong>Technical contact</strong>: <a
|
||||
href="mailto:philip@FreeBSD.org">&a.philip;</a></p>
|
||||
<p>The kernel is lacking a generic input device layer analogous to the Linux
|
||||
'input core' layer. Having such a layer would make it easy to write e.g.
|
||||
touchscreen support (&a.philip; has some work-in-progress regarding pointer
|
||||
devices and touchscreen support, but not enough time to also cover keyboard
|
||||
support or other generic features).</p>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Ability to read and understand foreign C code.</li>
|
||||
<li>Ability to write C code.</li>
|
||||
</ul><!-- netchild, philip -->
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-camlocking"></a>
|
||||
<h2>Add locking to the CAM layer</h2>
|
||||
<p><strong>Technical contact</strong>: <a
|
||||
href="mailto:scottl@FreeBSD.org">&a.scottl;</a></p>
|
||||
<p>&a.scottl; has been working on this for a while, and he has patches in
|
||||
Perforce.</p>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Ability to read and understand foreign C code.</li>
|
||||
<li>Ability to write C code.</li>
|
||||
<li>Knowledge about SCSI.</li>
|
||||
<li>A good understanding of the FreeBSD locking methods.</li>
|
||||
</ul><!-- netchild -->
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-iscsi"></a>
|
||||
<h2>Implement iSCSI</h2>
|
||||
<p><strong>Technical contact</strong>: <a
|
||||
href="mailto:danny@cs.huji.ac.il">Danny Braniss</a></p>
|
||||
<p>Danny Braniss has been working on an iSCSI stack for FreeBSD for some time
|
||||
now. His work is in Perforce, and he has posted several patch sets
|
||||
and had numerous discussions on the mailing lists.</p>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Ability to read and understand foreign C code.</li>
|
||||
<li>Ability to write C code.</li>
|
||||
<li>Knowledge about (i)SCSI/CAM.</li>
|
||||
</ul><!-- netchild -->
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-processcheck"></a>
|
||||
<h2>Port DragonFly's process checkpointing</h2>
|
||||
<p><strong>Technical contact</strong>: <a
|
||||
href="mailto:bruno@FreeBSD.org">&a.bruno;</a></p>
|
||||
<p>Process checkpointing allows to migrate some processes to other machines or
|
||||
to let some processes "survive" a reboot (subject to some constraints).
|
||||
Interesting files in the DragonFly CVS are sys/sys/ckpt.h, sys/checkpt/* and
|
||||
sys/kern/imgact_elf.c.</p>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Ability to read and understand foreign C code.</li>
|
||||
<li>Ability to write C code.</li>
|
||||
</ul><!-- netchild -->
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-memcpy"></a>
|
||||
<h2>Evaluate and perhaps port DragonFly's optimized memcpy/bcopy/bzero support
|
||||
subsystem (this includes an FPU subsystem overhaul)</h2>
|
||||
<p>Interesting files in the DragonFly CVS are sys/i386/gnu/fpemul/fpu_system.h,
|
||||
sys/i386/i386/bcopy.s, sys/i386/i386/genassym.c, sys/i386/i386/globals.s,
|
||||
sys/i386/i386/machdep.c, sys/i386/i386/math_emu.h,
|
||||
sys/i386/i386/mp_machdep.c, sys/i386/i386/pmap.c, sys/i386/i386/support.s,
|
||||
sys/i386/i386/swtch.s, sys/i386/i386/trap.c, sys/i386/i386/vm86bios.s,
|
||||
sys/i386/i386/vm_machdep.c, sys/i386/include/asmacros.h,
|
||||
sys/i386/include/globaldata.h, sys/i386/include/md_var.h,
|
||||
sys/i386/include/npx.h, sys/i386/include/pcb.h, sys/i386/include/thread.h
|
||||
sys/i386/isa/npx.c, sys/i386/i386/bcopy.s and sys/i386/i386/bzero.s. A more
|
||||
detailed writeup can be found in <a
|
||||
href="http://www.leidinger.net/FreeBSD/dfly_fpu.txt.bz2">this compressed
|
||||
file</a>. This includes a mail from Matthew Dillon with suggestions on how
|
||||
to do this in FreeBSD (including a small benchmark which shows 35%-55% speed
|
||||
improvement for at least those benchmarks).</p>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Ability to read and understand foreign C code.</li>
|
||||
<li>Ability to write C code.</li>
|
||||
<li>Knowledge of at least i386/MMX/XMM assembly.</li>
|
||||
<li>A good understanding of the FreeBSD SMP system.</li>
|
||||
<li>Roughly 6 weeks of free time.</li>
|
||||
</ul><!-- netchild -->
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-bootcode"></a>
|
||||
<h2>Evaluate and perhaps sync FreeBSD i386 boot code with DragonFly's boot
|
||||
code</h2>
|
||||
<p><strong>Technical contact</strong>: <a
|
||||
href="mailto:jhb@FreeBSD.org">&a.jhb;</a></p>
|
||||
<p>DragonFly invested a lot of time to clean-up and document it. Additionally
|
||||
they fixed some bugs. Interesting files in the DragonFly CVS are
|
||||
sys/boot/i386/bootasm.h, sys/boot/i386/bootasmdef.c, sys/boot/boot0/*,
|
||||
sys/boot/boot2/*, sys/boot/i386/btx/*, sys/boot/i386/cdboot/*,
|
||||
sys/boot/i386/libi386/amd64_tramp.S, sys/boot/i386/libi386/biosdisk.c and
|
||||
sys/boot/i386/loader/main.c. An interested volunteer has to compare both
|
||||
implementations and port interesting/good parts.</p>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Ability to read and understand foreign C code.</li>
|
||||
<li>Ability to write C code.</li>
|
||||
<li>Knowledge of i386 assembly.</li>
|
||||
<li>Knowledge of BIOS interfaces.</li>
|
||||
<li>Knowledge of low-level boot behavior.</li>
|
||||
</ul><!-- netchild -->
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-cpuusage"></a>
|
||||
<h2>Fix the CPU usage display in top for threaded processes</h2>
|
||||
<p>The current kernel statistics do not know how to calculate the CPU usage
|
||||
of threaded processes. A volunteer has to understand the current statistics
|
||||
model, design a new statistics model and implement it.</p>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Ability to read and understand foreign C code.</li>
|
||||
<li>Ability to write C code.</li>
|
||||
<li>A good understanding of the FreeBSD SMP system.</li>
|
||||
</ul><!-- netchild -->
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-pcihotplug"></a>
|
||||
<h2>Implement PCI-Hotplug support</h2>
|
||||
<p><!-- Description needed --></p>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Ability to read and understand foreign C code.</li>
|
||||
<li>Ability to write C code.</li>
|
||||
<li>A good understanding of low-level access of the hardware.</li>
|
||||
<li>A good understanding of the FreeBSD device drivers.</li>
|
||||
</ul><!-- netchild -->
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-dtrace"></a>
|
||||
<h2>Implement something similar to Solaris' DTrace</h2>
|
||||
<p><strong>Technical contact</strong>: <a
|
||||
href="mailto:dodell@iXsystems.com">Devon H. O'Dell</a></p>
|
||||
<p><strong>URL</strong>: <a href="http://www.sitetronics.com:8080/">Perforce
|
||||
repository</a></p>
|
||||
<p>Need to get the DTrace provider working. This is the epicenter of DTrace
|
||||
and it is the first step to making the rest of it work from the kernel side
|
||||
of things. Userland stuff is 98% done. The other 2% will be addressed later
|
||||
when some kernel dependencies are satisfied.</p>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Ability to read and understand foreign C code.</li>
|
||||
<li>Ability to write C code.</li>
|
||||
<li>A good understanding of the FreeBSD kernel.</li>
|
||||
</ul><!-- netchild -->
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-amd64linux"></a>
|
||||
<h2>Add amd64 native support to the Linuxulator</h2>
|
||||
<p>FreeBSD provides Linux binary compatibility through a Linux system call
|
||||
table that is invoked when Linux ELF binaries are executed. The
|
||||
implementation on amd64 machines only provides support for 32bit (x86)
|
||||
executables. This needs to be coordinated with the <a
|
||||
href="mailto:emulation@FreeBSD.org">emulation mailinglist</a> regarding
|
||||
the userland part of the linuxulator.</p>
|
||||
<ul>
|
||||
<li>Determine a way how to distinguish between 32 bit and 64 bit applications
|
||||
when entering a system call.</li>
|
||||
<li>Design and implement 64 bit support while keeping 32 bit support.</li>
|
||||
</ul>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Ability to read and understand foreign C code.</li>
|
||||
<li>Ability to write C code.</li>
|
||||
<li>A good understanding of how to do a clean room implementation of GPL'ed
|
||||
code (no copy & paste!).</li>
|
||||
</ul><!-- netchild -->
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-updatelinux"></a>
|
||||
<h2>Update the Linuxulator</h2>
|
||||
<p>FreeBSD provides Linux binary compatibility through a Linux system call
|
||||
table that is invoked when Linux ELF binaries are executed. This
|
||||
implementation should be compared with an up-to-date Linux kernel so that
|
||||
important missing syscalls can be added to ensure that all mainstream
|
||||
applications continue to work on FreeBSD.</p>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Ability to read and understand foreign C code.</li>
|
||||
<li>Ability to write C code.</li>
|
||||
<li>A good understanding of how to do a clean room implementation of GPL'ed
|
||||
code (no copy & paste!).</li>
|
||||
</ul><!-- netchild -->
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-assembler"></a>
|
||||
<h2>Annotate every assembler file [*.[sS]] with dwarf2 call frame
|
||||
information</h2>
|
||||
<p>A debug kernel is not able to show stack traces with cross exceptions
|
||||
anymore. This is because we do not emit any dwarf2 call frame information
|
||||
for any assembler code, since gdb switched to the dwarf2 format.</p>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Knowledge of assembly code.</li>
|
||||
<li>Knowledge of ".cfa_*" pseudo-ops to insert dwarf2 frame descriptors.</li>
|
||||
</ul><!-- netchild: peter via arch -->
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-suspend"></a>
|
||||
<h2>Suspend to disk</h2>
|
||||
<p><strong>Technical contacts</strong>: <a
|
||||
href="mailto:njl@FreeBSD.org">&a.njl;</a>, <a
|
||||
href="mailto:bruno@FreeBSD.org">&a.bruno;</a></p>
|
||||
<p>Implement a suspend/resume from disk mechanism. Possibly use the dump
|
||||
functions to dump pages to disk, then use ACPI to put the system in S4 or
|
||||
power-off. Resume would require changes to the loader to load the memory
|
||||
image directly and then begin executing again.</p>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Good knowledge of C.</li>
|
||||
<li>Understanding of the hardware/software interface.</li>
|
||||
<li>A laptop that works with ACPI.</li>
|
||||
<li>Kernel awareness.</li>
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-zeroconf"></a>
|
||||
<h2>Add zeroconf (Rendezvous/Bonjour) support to FreeBSD</h2>
|
||||
<p><!-- Description needed --></p>
|
||||
<ul>
|
||||
<li>Find/write a suitable zeroconf implementation.</li>
|
||||
<li>Add zeroconf support to the base system daemons.</li>
|
||||
</ul>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Ability to read and understand foreign C code.</li>
|
||||
<li>Ability to write C code.</li>
|
||||
</ul><!-- netchild -->
|
||||
|
||||
<hr>
|
||||
|
||||
<!--
|
||||
<a name="p-isdn4bsd"></a>
|
||||
<h2>Modernize ISDN4BSD</h2>
|
||||
<p>Description needed</p>
|
||||
<ul>
|
||||
<li>Re-factor i4b to allow to implement locking.</li>
|
||||
<li>Modernize the use of kernel APIs in i4b, e.g. use busspace(9)</li>
|
||||
<li>Test/fix it on amd64.</li>
|
||||
<li>Determine the requirements of external software like asterisk and add
|
||||
missing interfaces.</li>
|
||||
<li>Write/add drivers which get recommended by asterisk.</li>
|
||||
</ul>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Ability to read and understand foreign C code.</li>
|
||||
<li>Ability to write C code.</li>
|
||||
<li>Knowledge about ISDN.</li>
|
||||
<li>Knowledge about device driver APIs.</li>
|
||||
<li>A good understanding of the FreeBSD locking methods.</li>
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
-->
|
||||
|
||||
<a name="p-networkdisk"></a>
|
||||
<h2>Network Disk Device</h2>
|
||||
<p><strong>Technical contact</strong>: <a
|
||||
href="mailto:alfred@FreeBSD.org">&a.alfred;</a></p>
|
||||
<p>Add the ability to remotely access devices from one system to another. The
|
||||
goal is to allow remote access to resources such as disks, sound devices,
|
||||
and other miscellaneous pieces of hardware over the network. This project
|
||||
would be a good resume builder, but is not for the faint of heart.</p>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Understanding or interest in remote procedure call systems.</li>
|
||||
<li>Understanding or interest in networking (TCP/IP).</li>
|
||||
<li>Interest to learn how &unix; device drivers work as well as process
|
||||
management.</li>
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-nfslockdsemantics"></a>
|
||||
<h2>NFS Lockd (improve semantics)</h2>
|
||||
<p><strong>Technical contact</strong>: <a
|
||||
href="mailto:alfred@FreeBSD.org">&a.alfred;</a></p>
|
||||
<p><!-- Description needed --></p>
|
||||
<ul>
|
||||
<li>Improve the semantics of the NFS lockd in FreeBSD. Apple has made
|
||||
certain enhancements that can be leveraged in our code base.</li>
|
||||
<li>Implement state recovery in the lockd.</li>
|
||||
</ul>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Good knowledge of C.</li>
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-nfslockdkernel"></a>
|
||||
<h2>NFS Lockd (kernel implementation)</h2>
|
||||
<p><strong>Technical contact</strong>: <a
|
||||
href="mailto:alfred@FreeBSD.org">&a.alfred;</a></p>
|
||||
<p>Moving the lockd implementation into the kernel provides several key
|
||||
performance and semantic improvements.</p>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Good knowledge of C.</li>
|
||||
<li>Good understanding of NFS.</li>
|
||||
<li>Good understanding of locking.</li>
|
||||
<li>Good understanding of RPC.</li>
|
||||
<li>Good understanding of kernel level networking.</li>
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-web100"></a>
|
||||
<h2>Port Web100 to FreeBSD</h2>
|
||||
<p><strong>Technical contact</strong>: <a
|
||||
href="mailto:brooks@FreeBSD.org">&a.brooks;</a></p>
|
||||
<p><strong>URL</strong>: <a
|
||||
href="http://www.web100.org/">The Web100 project</a></p>
|
||||
<p>The Web100 project was created to address the problems of TCP performance
|
||||
over long-fat network pipes. They created an interesting set of tuning and
|
||||
monitoring patches for Linux which enable significantly better performance
|
||||
in this area. Integrating this work into FreeBSD could provide significant
|
||||
benefits in terms of TCP performance in certain environments.</p>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Good knowledge of C.</li>
|
||||
<li>The features of Web100 need to be mapped into appropriate FreeBSD
|
||||
abstractions and integrated into the system.</li>
|
||||
<li>The performance impact of these changes would have to be quantified
|
||||
before the changes could be introduced.</li>
|
||||
<li>Good understanding of the TCP protocol.</li>
|
||||
<li>Good understanding of kernel interfaces.</li>
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-securemines"></a>
|
||||
<h2>SecureMines</h2>
|
||||
<p><strong>Technical contact</strong>: <a
|
||||
href="mailto:alfred@FreeBSD.org">&a.alfred;</a></p>
|
||||
<p>Add meta-data to the system in order to trap intruders and provide an audit
|
||||
log. The goal of this project is to create several means of marking an event
|
||||
as a foreign act (such as opening a trap file) which halts the system and
|
||||
provides as much information as possible, possibilities include using
|
||||
extended attributes to tag such "mines".</p>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Good knowledge of C.</li>
|
||||
<li>Good understanding of the Unix process model.</li>
|
||||
<li>Good understanding of the FreeBSD kernel.</li>
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-sysinstall"></a>
|
||||
<h2>Small sysinstall renovation</h2>
|
||||
<p><!-- Description needed --></p>
|
||||
<ul>
|
||||
<li>Ask for country & keyboard layout at start - so international keyboards
|
||||
work correctly.</li>
|
||||
<li>Ask for network configuration before install - so you do not have to
|
||||
configure the net twice.</li>
|
||||
<li>Get hostname from dhcp server as well.</li>
|
||||
<li>Make a guess of the timezone based upon country & keyboard.</li>
|
||||
<li>Write the FreeBSD version at the top of the display (or somewhere similar
|
||||
visible) - so lazy users know what they are installing (version: release,
|
||||
stable, snapshot + arch: i386, amd64, etc) even when the CD is
|
||||
unlabeled.</li>
|
||||
<li>Other usability improvements not yet thought of.</li>
|
||||
</ul>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Good C knowledge (reading and writing).</li>
|
||||
<li>No fear regarding "naturally grown" code.</li>
|
||||
</ul><!-- Martin Nilsson <martin@mullet.se> -->
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-pxeinstaller"></a>
|
||||
<h2>Bundled PXE Installer</h2>
|
||||
<p>It would be great to have a bundled PXE installer. This would allow one to
|
||||
boot an install server from a FreeSBIE live CD-ROM on one box, set the BIOS
|
||||
on subsequent boxes to PXE boot, and then have the rest happen by magic.
|
||||
This would be very helpful for installing cluster nodes, etc.</p>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Good PXE knowledge.</li>
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-regression"></a>
|
||||
<h2>Improve our regression testing system</h2>
|
||||
<p><strong>Technical contact</strong>: <a
|
||||
href="mailto:nik@FreeBSD.org">&a.nik;</a></p>
|
||||
<p>&a.nik; has written a regression test infrastructure using Perl. More of
|
||||
the regression tests should be made to work with libtap.</p>
|
||||
<ul>
|
||||
<li>Many of the existing tests should be moved from using assert() to using
|
||||
ok() and friends from libtap.</li>
|
||||
<li>More regression tests should be written.</li>
|
||||
</ul>
|
||||
<p><strong>Requirements</strong>:</p>
|
||||
<ul>
|
||||
<li>Good knowledge of scripting languages (perl preferred).</li>
|
||||
<li>Good knowledge of software testing.</li>
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-performancetracking"></a>
|
||||
<h2>Tracking performance over time</h2>
|
||||
<p><strong>Technical contact</strong>: <a
|
||||
href="mailto:brooks@FreeBSD.org">&a.brooks;</a></p>
|
||||
<p>One of the major issues in a project with the size of FreeBSD is monitoring
|
||||
changes in performance characteristics over time. Doing this requires
|
||||
several things. Those include a suite of appropriate tests, hardware to
|
||||
run the tests on, a database to store results in, and software to
|
||||
extract interesting results and display them. Solving the whole problems
|
||||
is probably beyond the scope of one summer's work, but an interesting
|
||||
subset should be manageable.</p>
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-projects"></a>
|
||||
<h2>Projects at FreeBSD.org</h2>
|
||||
<p>Additional projects may be found by browsing the <a
|
||||
href="../projects.html">FreeBSD Development Projects page</a>. The most
|
||||
prominent projects are:</p>
|
||||
<ul>
|
||||
<li><a href="../acpi/index.html">The FreeBSD ACPI Project</a></li>
|
||||
<li><a href="../c99/index.html">C99 & POSIX Conformance Project</a></li>
|
||||
<li><a href="../bigdisk/index.html">Large data storage in FreeBSD
|
||||
Project</a></li>
|
||||
<li><a href="../netperf/index.html">Network Performance Project</a></li>
|
||||
<li><a href="../dingo/index.html">Network Cleanup and Consolidation
|
||||
Project</a></li>
|
||||
<li><a href="../busdma/index.html">busdma and SMPng driver conversion
|
||||
Project</a></li>
|
||||
</ul>
|
||||
<p>Do not forget to have a look at the other projects too or by viewing some
|
||||
of the recent <a href="&base;/news/status">Developer Status Reports.</a></p>
|
||||
|
||||
<hr>
|
||||
|
||||
<a name="p-tc"></a>
|
||||
<h2>Technical contacts</h2>
|
||||
<p>If you are interested in working on a project not explicitly
|
||||
mentioned above, you may want to contact one of the potential
|
||||
technical contacts below:</p>
|
||||
<ul>
|
||||
<li><strong>ACPI</strong>:
|
||||
<a href="mailto:njl@FreeBSD.org">&a.njl;</a>
|
||||
<a href="mailto:bruno@FreeBSD.og">&a.bruno;</a>.</li>
|
||||
<li><strong>File systems</strong>:
|
||||
<a href="mailto:scottl@FreeBSD.org">&a.scottl;</a>,
|
||||
<a href="mailto:alfred@FreeBSD.org">&a.alfred;</a>.</li>
|
||||
<li><strong>GEOM</strong>:
|
||||
<a href="mailto:phk@FreeBSD.org">&a.phk;</a>.</li>
|
||||
<li><strong>Networking</strong>:
|
||||
<a href="mailto:alfred@FreeBSD.org">&a.alfred;</a>,
|
||||
<a href="mailto:brooks@FreeBSD.org">&a.brooks;</a>,
|
||||
<a href="mailto:sam@FreeBSD.org">&a.sam;</a>.</li>
|
||||
<li><strong>Release Engineering / Integration</strong>:
|
||||
<a href="mailto:re@FreeBSD.org">Release Engineering Team</a>.</li>
|
||||
<li><strong>Sound</strong>:
|
||||
<a href="mailto:ariff@FreeBSD.org">&a.ariff;</a>.</li>
|
||||
<li><strong>TrustedBSD / Security</strong>:
|
||||
<a href="mailto:rwatson@FreeBSD.org">&a.rwatson;</a>.</li>
|
||||
</ul>
|
||||
<p>Additionally, there are a lot of interesting <a
|
||||
href="&base;/doc/en_US.ISO8859-1/books/handbook/eresources.html#ERESOURCES-MAIL">mailing
|
||||
lists</a> that can be used when searching information about specific
|
||||
subjects.</p>
|
||||
|
||||
<hr>
|
||||
|
||||
&footer;
|
||||
</body>
|
||||
</html>
|
||||
38
en/projects/ideas/style.css
Normal file
38
en/projects/ideas/style.css
Normal file
|
|
@ -0,0 +1,38 @@
|
|||
BODY {
|
||||
}
|
||||
|
||||
BODY TD {
|
||||
font-size: 13px;
|
||||
}
|
||||
|
||||
BODY SMALL {
|
||||
width: 615px;
|
||||
font-size: 11px;
|
||||
}
|
||||
|
||||
.heading {
|
||||
font-size: 15px;
|
||||
background-color: #cbd2ec;
|
||||
}
|
||||
|
||||
.section {
|
||||
font-size: 15px;
|
||||
font-weight: bold;
|
||||
background-color: #e7e9f7;
|
||||
}
|
||||
|
||||
.notes {
|
||||
font-size: 13px;
|
||||
font-weight: normal;
|
||||
}
|
||||
|
||||
.main {
|
||||
width: 615px;
|
||||
height: auto;
|
||||
text-align: justify;
|
||||
}
|
||||
|
||||
.list {
|
||||
width: 550px;
|
||||
height: auto;
|
||||
}
|
||||
Loading…
Reference in a new issue