Scott Long recently submitted a list of "nice-to-have" projects for the next 12-months and future releases in general. Many comments and addendums are suggested by various developers and committers. Topics including the adoption of Dragonfly BSD's extensible bsdinstaller (among others) as a worthy sysinstall replacement, ongoing development of ReiserFS4 support for FreeBSD, interesting discussion concerning clustered filesystem support, comments on SANs and much more.

"Most of these tasks are
not trivial, but I hope that talking about them will encourage some
interest. [...]While this is just my personal list, I'd welcome
other additions to it (in the sense of significant projects, not just
individual PRs or bug fixes that one might be interested in)."

From: Scott Long [email blocked]
To: freebsd-current
Subject: My projects wish-list for the next 12 months
Date: 2004-12-01 22:02:40

All,

I know that I said last month that we were going to stop promising
specific features for the next major release.  However, I'd like to
throw out a list of things that would be really nice to have in the
future, whether its 6.0 or 7.0 or whatever.  Most of these tasks are
not trivial, but I hope that talking about them will encourage some
interest.  These are in no particular priority order.  I'd also be
thrilled if someone wanted to dress this list up in docbook and add
it to the webpage.  While this is just my personal list, I'd welcome
other additions to it (in the sense of significant projects, not just
individual PRs or bug fixes that one might be interested in).

1.  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.

2.  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.

3.  Native PCI Express support.  I keep on hoping to take care of this,
but I never seem to have the time to get past designing it.  This task
includes 3 parts that are mostly independent.  The first is support for
the extended PCI config space and memio access method, the second is
MSI, and the third is link QOS management.  If anyone is interested
here, please let me know.

4.  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.

5.  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.

6.  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.


Related Links:


  
Archive of the above thread