Scott Long
This is my wish list and TODO page. Some of these are things that I might be working on, some are things that I wish I could work on. All of them are things that I think are important to the project.
Storage:
- Real software RAID infrastructure. GEOM provides a good foundation, and the various g_* classes are good transforms, but they lack the integration that is needed for reliable error recovery and multiple metadata support. Software RAID is becoming a commodity and we need to both support it reliably and support the dozens of vendors out there, especially Adaptec, Promise, Highpoint, and LSI. Writing and testing the infrastructure and writing a couple of metadata modules is probably a 3-4 month project.
- CAM locking. CAM is only of the last major I/O subsystems to be left under the Giant lock. It's holding back all of the SCSI drivers from performing well. I've started a branch in perforce under //depot/projects/scottl-camlock/src/sys/... The work so far has been focused on turning the probe logic into an event-driven thread in order to eliminate the possibility of locking problems.
- Overhaul CAM, add iSCSI. CAM is very parallel-SCSI centric right now. I have some work-in-progress in Perforce to address this, but it's pretty minimal. The parallel SCSI knowledge needs to be separated out and the stack need to be able to cleanly deal with iSCSI, SCSI, SAS, and maybe even ATA transports. There is a Lucent implementation of iSCSI for FreeBSD 4.x that could be a useful reference, though it's a monolithic stack that doesn't really address the shortcomings of CAM. Having iSCSI infrastructure that supported both hardware and software implementations would be ideal.
- Journaled filesystem. While we can debate the merits of speed and data integrety of journalling vs. softupdates, the simple fact remains that softupdates still requires a fsck run on recovery, and the multi-terabyte filesystems that are possible these days make fsck a very long and unpleasant experience, even with bg-fsck. There was work at some point at RPI to add journaling to UFS, but there hasn't been much status on that in a long time. There have also been proposals and works-in-progress to port JFS, ReiserFS?, and XFS. Some of these efforts are still alive, but they need to be seen through to completion. But at the risk of opening a can of worms here, I'll say that it's also important to explore non-GPL alternatives.
Clustered FS support. SANs are all the rage these days, and clustered filesystems that allow data to be distributed across many storage enpoints and accessed concurrently through the SAN are very powerful. RedHat? recently bought Sistina and re-opened the GFS source code, so exploring this would be very interesting.
Infrastructure:
- Keyboard multiplexer. We are running into problems with making ps/2 and USB/bluetooth keyboards work together and work with KVMs. Having a virtual keyboard device that multiplexes the various real keyboard devices and handles hotplug can solve this mess pretty effectively. I know that there has been a lot of talk about this on mailing lists recently but I don't know how much progress is being made so I'm listing it here.
- New installer. I know some people still consider this a joke, but the reality is that sysinstall is no longer state of the art. It's fairly good at the simple task that it does, but it's becoming harder and harder to fix bugs and extend functionality in it. It's also fairly unfriendly to those of us who haven't been using it since 1995. The DFly folks have some very interesting work in this area (www.bsdinstaller.com) and it would be very good to see if we can collaborate with them on it.
- Native PCI Express support. I've committed a prototype for the native memory-mapped extended configuration mechanism, but it needs to be integrated with ACPI. After that, MSI and MSI-X needs to be addressed. Hot-plug and virtual channel/QOS support would also be very nice to have.
Release Engineering:
- Install both UP and SMP kernels via sysinstall, and have it enable the correct one. This isn't terribly hard, just takes some motivation.
- Combine the existing disc1 and disc2 into a single disk, and stop putting packages on disc1. I'd like to see a system where a FreeBSD release is just the base system bits, and the FreeBSD vendors take that and add to it via secondary discs. We could still provide a sample disc2 with the packages that are on disc1 right now. Moving to this model also alleviates the space crunch that we have with disc1 right now due to packages and the base system continuously growing.