Add a few filesystem and misc. kernel project ideas suggested by Kris.

Submitted by:	     kris@

en/projects/ideas/ideas.xml

@@ -15,7 +15,7 @@ Ideas//EN"
 <ideas>
   <cvs:keywords xmlns:cvs="http://www.FreeBSD.org/XML/CVS" version="1.0">
     <cvs:keyword name="freebsd">
-      $FreeBSD: www/en/projects/ideas/ideas.xml,v 1.49 2008/03/18 04:08:21 murray Exp $
+      $FreeBSD: www/en/projects/ideas/ideas.xml,v 1.50 2008/03/18 04:24:39 murray Exp $
     </cvs:keyword>
   </cvs:keywords>
 
@@ -239,11 +239,87 @@ these buses to be a subclass of this new base class.</p>
       </desc>
     </idea>
 
+    <idea id="mpsafe-filesystem-work" class="soc">
+      <title>MPSAFE filesystem work</title>
+
+      <desc>
+        <p><strong>Technical contact</strong>: <a href="mailto:kris@FreeBSD.org">Kris Kennaway</a></p>
+
+	<p>Take a filesystem and MPSAFE it.  e.g. ext2fs, ntfs, coda, etc.</p>
+      </desc>
+    </idea>
+
   </category>
 
   <category>
     <title>Kernel</title>
 
+    <idea id="ddb-gdb-scripting" class="soc">
+      <title>DDB/gdb scripting</title>
+
+      <desc><p><strong>Technical contact</strong>: <a href="mailto:kris@FreeBSD.org">Kris Kennaway</a></p>
+
+      <p>The goal would be to develop scripts that automatically run a
+        standard suite of useful debugging commands in DDB upon panic
+        and save in a textdump.  Might be too short on its own, so
+        could be combined with a project to write gdb macro
+        equivalents of the DDB command set, extending the macros John Baldwin
+        has.  New DDB commands and macros could also be implemented,
+        e.g. for inspecting other common data structures.</p>
+      </desc>
+    </idea>
+
+    <idea id="fifo-optimizations" class="soc">
+      <title>FIFO optimizations</title>
+
+      <desc><p><strong>Technical contact</strong>: <a href="mailto:kris@FreeBSD.org">Kris Kennaway</a></p>
+
+      <p>Evaluate the possibility of merging the FIFO implementation
+        with the pipe implementation for improved performance.  Care
+        would need to be taken to avoid regressions, so part of this
+        project should be attention to previous and existing FIFO bug
+        reports, and writing of conformance testing to verify correct
+        behaviour.  Possible extensions might include a re-evaluation
+        of some of the performance tradeoffs made in the pipe code in
+        light of modern CPUs.</p>
+      </desc>
+    </idea>
+
+    <idea id="pmc-modern-cpus" class="soc">
+      <title>PMC support for modern CPUs</title>
+
+      <desc><p><strong>Technical contact</strong>: <a href="mailto:jkoshy@FreeBSD.org">Josef Koshy</a></p>
+
+      <p>Part of this project would be to add support to PMC for
+        running on modern x86 CPUs.  This is a relatively
+        self-contained project but requires a bit of immersion in the
+        code and the CPU manuals.</p>
+
+      </desc>
+    </idea>
+
+    <idea id="timecounter-perf" class="soc">
+      <title>Timecounter Performance Improvements</title>
+
+      <desc>
+        <p><strong>Technical contact</strong>: <a href="mailto:kris@FreeBSD.org">Kris Kennaway</a></p>
+
+	<p>The gettimeofday syscall is a performance bottleneck in
+	  certain applications.  An approach taken by other operating
+	  systems is to export the time counter to userland via a
+	  shared page, and to update it periodically (a prototype
+	  implementation is available).  For some time consumers this
+	  is sufficient resolution.  Other consumers need higher
+	  resolution.  On the x86 architecture the TSC timecounter can
+	  be read from userland.  However depending on the hardware
+	  there may be issues with synchronization between CPUs, as
+	  well as interaction with CPU frequency changes.  With care
+	  it can be used as a delta against the timestamp updated by
+	  the kernel to provide improved resolution and avoid the need
+	  for the syscall.</p>
+      </desc>
+    </idea>
+
     <idea id="autoreport" class="soc">
       <title>Automated kernel crash reporting system</title>