Date: Wed, 01 Dec 2004 23:14:39 +0100 From: Andre Oppermann <andre@freebsd.org> To: Scott Long <scottl@freebsd.org> Cc: "current@freebsd.org" <current@freebsd.org> Subject: Re: My project wish-list for the next 12 months Message-ID: <41AE424F.1010707@freebsd.org> In-Reply-To: <41AE3F80.1000506@freebsd.org> References: <41AE3F80.1000506@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Scott Long wrote: > 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. Seeing all this storage related stuff is very interesting because I just stumbled across a company making a new digital Cinematography system that has 8Mpix and they say that using this in a day's worth shooting they end up with up to 6.63TB of raw digigal footage. In the end this is 398TB for an average feature movie. The camera delivers the images over quad-infiniband to the recording system at 400MB/s. Pretty impressive. http://www.dalsa.com/dc/workflow/storage.asp -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41AE424F.1010707>