Ideas on this page are viewed as obsolete. Although some tasks here still may be of some benefit, there are generally reasons why they don't make a good area to focus effort on. For example, some may refer to improvements in software which is obsolete, or scheduled for replacement. Others may have proven to be a bad idea through testing either by other FreeBSD devs or by work in other projects. Others may have simply already been done. Before embarking on a task on this page, it would be very much worth your while finding out exactly why it ended up here - there is every possibility that effort put into these tasks would be wasted effort

(Re)implement the BFS scheduler in FreeBSD

Suggested Summer of Code 2011 project idea

The BFS scheduler is a relatively simple scheduler curiously similar to the 4BSD scheduler but apparently even simpler and with improvements for machines with a relatively small number of CPUs (<= 16). It would be good to see how it compares to current FreeBSD schedulers, which are fairly complex.


Geom-based Disk Schedulers (obsolete)

Suggested Summer of Code 2009 project idea

Note: with geom_sched in the system and SSD devices more and more popular, there isn't a real need to do further work on this project

Technical Contact:

In a 2005 GSoC project, "Pluggable Disk Schedulers", Emiliano Mennucci explored the feasibility of pluggable disk schedulers for FreeBSD. The project was successful, but we could not explore certain approaches (e.g. "anticipation", where requests are delayed hoping that some future ones can served without a seek) due to architectural limitations the kernel had at the time.

Since then, the GEOM infrastructure has become available on FreeBSD for interacting with disk I/O requests. GEOM has enabled us to work on disk schedulers in a much more flexible way, allowing a much faster development of disk scheduling algorithms. With Fabio Checconi, we have developed a prototype implementation of some anticipatory schedulers, see GEOM_SCHED. works within the geom layer, i.e. above the device driver where queueing of requests may actually occur. The way GEOM_SCHED does scheduling is by limiting the number of outstanding requests to the device, and the performance implications of this approach need to be measured. An alternative approach is to push the scheduler (using the same algorithms developed in GEOM_SCHED, and most likely the same code) within the device drivers. This less general (as it needs to be replicated in all drivers) but it may be an interesting thing to do e.g. for some popular device drivers such as ATA.

The proposed SoC work can address one or more of the following aspects:

Ultimately, we expect to end up with a production quality subsystem for use in FreeBSD.

References: The Pluggable Disk Schedulers SoC project,


Ports license auditing infrastructure

Part of Summer of Code 2008 Done during Summer of Code 2008

Technical Contact: kris@, brooks@

Develop and deploy infrastructure for annotating license conditions that apply to third party software in the ports collection. For example, identifying ports provided under the GPL version 3 license, or under licenses that do not permit redistribution or which impose non-standard requirements. Part of this project will involve exploring methods for automatically classifying licenses using HP's fossology tool ( or other mechanisms.


Finish porting FUSE to FreeBSD (GSoC)

Suggested Summer of Code 2012 project idea

Contact Info

Technical Contact: ivoras@


The FUSE kernel module was partially ported by a previous Summer of Code project as fuse4bsd, and continued as a GSoC project 2011. The port is reasonably complete but suffers from stability and data corruption issues which make it unusable for day-to-day use. This project would continue that port. The practical goals of the project would be to identify the issues in the port which cause crashes and memory corruption, fix them, update the port to newer version of FUSE, and fix the module so that the file system passes FreeBSD's fsx and fstest regression tests on at least sshfs.



Due to previous unfinished attempts to port FUSE, the GSoC project will not be considered complete and the student will not be given a "pass" grade until the port successfully passes file system tests.

Timecounter Performance Improvements (GSoC)

Suggested Summer of Code project idea

Contact Info

Technical Contact:


The gettimeofday syscall is a performance bottleneck in certain applications. An approach taken by other operating systems is to export the time counter to userland via a shared page, and to update it periodically (a prototype implementation is available). For some time consumers this is sufficient resolution. Other consumers need higher resolution. On the x86 architecture the TSC timecounter can be read from userland. However depending on the hardware there may be issues with synchronization between CPUs, as well as interaction with CPU frequency changes. With care it can be used as a delta against the timestamp updated by the kernel to provide improved resolution and avoid the need for the syscall.

Kernel support for linux DVB device drivers (obsolete)

Suggested Summer of Code 2009 project idea

Technical Contact: luigi@

note: this project is obsolete, people should use multimedia/webcamd


In early 2007 we started a project to support building Linux device drivers on FreeBSD. This was done through an in-kernel emulation layer, which implements part of the linux kernel API on top of the FreeBSD kernel API. The initial implementation was good enough to support a few USB webcam drivers, and is documented here. The code is actually available as a port, devel/linux-kmod-compat, and a popular driver that uses this infrastructure is multimedia/linux-gspca-kmod.

We would like to use a similar approach to add support for DVB devices, which are widely supported in Linux but not in FreeBSD. In particular we expect the project to provide, within the FreeBSD kernel, enough of linux compatibility to build the core components of the drivers/media/ linux kernel, and then a few device drivers including one for a PCI DVB card (e.g. saa7134-based).

Before the start of the project, a Summer of Code applicant is expected to i) become familiar with the approach used by linux-kmod-compat; ii) set up a proper test environment, with a couple of DVB devices supported by linux, and a working linux installation so that one can compare results; iii) become familiar with the architecture of the linux code in drivers/media. Probably the attention should be focused in PCI devices, because at this stage the USB stack is in a transition phase and would pose some additional difficulties.

Expected results are a working porting infrastructure, a working linux-dvb-kmod device driver, and a working application to demonstrate that the driver is working as expected. We suggest to look at "kaffeine" for which a FreeBSD port already exists.

Info: USB based DVB devices are already supported by the multimedia/webcamd port on FreeBSD 8.x+ and work is underway to enable the use of them from linux programs (native FreeBSD programs are alaready able to use them).


Do either of these apply to bsdinstall now?


IdeasPage/Attic (last edited 2012-03-16 22:14:50 by MarkLinimon)