Re: My project wish-list for the next 12 months

des_at_ 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"