My project wish-list for the next 12 months
Divacky Roman
xdivac02 at stud.fit.vutbr.cz
Thu Dec 2 08:01:31 PST 2004
des@ raised question realting to implementition of anticipatory scheduler..
http://www.cs.rice.edu/~ssiyer/r/antsched/
shouldnt this be integrated or something?
On Wed, Dec 01, 2004 at 03:02:40PM -0700, 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.
>
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
More information about the freebsd-current
mailing list