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.
- Good knowledge of C
- Knowledge of what system process scheduling actually is
- Ability to do a "clean room" reimplementation of the GPL code as BSD code
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: email@example.com
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.
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:
- implement suitable classifiers for disk requests;
- implement techniques for the auto-tuning of the scheduler parameters;
- measure the performance implications of doing scheduling above the device driver, and possibly design and implement a suitable mechanism to push the GEOM_SCHED module within the device driver itself.
Ultimately, we expect to end up with a production quality subsystem for use in FreeBSD.
References: The Pluggable Disk Schedulers SoC project.
- Ability to read and understand foreign C code.
- Ability to write C code.
- Knowledge of GEOM (or interest in getting familiar with it).
Ports license auditing infrastructure
Part of Summer of Code 2008 Done during Summer of Code 2008
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 Fossology or other mechanisms.
- Familiarity with bsd.port.mk and related ports collection infrastructure.
Finish porting FUSE to FreeBSD (GSoC)
Suggested Summer of Code 2012 project idea
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.
- Strong knowledge of C.
- Understanding of file systems and VFS kernel interfaces
- Understanding of how FUSE works from the user side
- Understanding of kernel debugging.
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
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?
- Ask for network configuration before install - so you do not have to configure the net twice.
- Make a guess of the timezone based upon country and keyboard.
- Good C knowledge (reading and writing).
- No fear regarding "naturally grown" code.