Long overdue ideas list update:

- update existing entries
 - remove finished/obsolete entries
   * GNOME freebsd update frontend
   * sensors framework
   * CPU display in top (libkse related)
 - add new entries
   * OpenBSD's bio framework
   * adapt drivers to sensors framework
   * cron/atrun
   * on-disk indexing for UFS2
   * co-location for UFS2
   * porting NetBSD's ext2fs
   * optional kernel subsys register via sysctl

Discussed with:	bz, jkoshy, marcus, yar, kris, emaste
		Matus Harvan <mharvan@inf.ethz.ch>,
		Erik Cederstrand <erik@cederstrand.dk>,
		Nikolay Pavlov <qpadla@gmail.com>,
		pfgshield-freebsd@yahoo.com,

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.24 2007/05/01 18:08:41 netchild Exp $
+      $FreeBSD: www/en/projects/ideas/ideas.xml,v 1.25 2007/06/18 19:57:06 netchild Exp $
     </cvs:keyword>
   </cvs:keywords>
 
@@ -62,8 +62,75 @@ Ideas//EN"
 <ul>
   <li>Knowledge of C programming.</li>
   <li>Basic understanding of backup/restore procedures.</li>
-</ul></desc>
+</ul>
+      </desc>
+    </idea>
 
+    <idea id="extendufs2">
+      <title>Extend UFS2 with on-disk indexing</title>
+
+      <desc><p>The section <emph>8.3 Naming</emph> of the book
+        <emph>Design and Implementation of FreeBSD operation system<emph>
+        describes the current approach of name lookups in UFS2 and a possible
+        extension/improvement by utilizing on-disk indexing in a backward
+        compatible way. While the current approach (an in-memory directory cache)
+        is 90% effective when hit, it is only applicable to 25% of name lookups.
+        On-disk indexing would improve this situation.</p>
+<p><strong>Requirements</strong>:</p>
+<ul>
+  <li>Knowledge of C programming.</li>
+  <li>Basic understanding of filesystems.</li>
+  <li>The book <emph>Design and Implementation of FreeBSD operation system<emph>.</li>
+</ul>
+      </desc>
+    </idea>
+
+    <idea id="portext2fs">
+      <title>Port NetBSD's ext2fs and teach it to use gjournal</title>
+
+      <desc><p>FreeBSD has an implementation of the ext2fs filesystems
+        but it contains some files under the GPL which make it undesirable,
+        among other things, to use it in the GENERIC kernel. Ext2fs is a rather
+        simple but practical filesystem and NetBSD has had for <a
+        href="http://ezine.daemonnews.org/200006/ext2fs.html">a while</a>
+        an <a href="http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/ufs/ext2fs/">
+        implementation</a> based on UFS1 sources. Linux has several
+        interesting filesystems but most distributions seem to be gravitating
+        towards ext3fs, which supports the same on-disk format as ext2fs and
+        adds journalling. Porting NetBSD's ext2fs and adding support for in
+        gjournal (if possible) would make an excellent combination. Other
+        desirables possibilities would be to implement EA/ACLs and to use
+        it as root filesystem.</p>
+<p><strong>Requirements</strong>:</p>
+<ul>
+  <li>Knowledge of C programming.</li>
+  <li>Basic understanding of filesystems.</li>
+</ul>
+      </desc>
+    </idea>
+
+    <idea id="colocation">
+      <title>Implement co-location for UFS2</title>
+
+      <desc><p>While FreeBSD's FFS implementation is pretty much
+        state-of-the-art, in addition to softupdates, Greg Granger <a
+        href="http://www.ece.cmu.edu/~ganger/papers/cffs.html">proposed</a>
+        other stategies that would be useful, especially when working
+        with small files. Quoting Greg Ganger: "The key insight for why
+        current file systems perform poorly is that locality is insufficient
+        - exploiting disk bandwidth for small data objects requires that
+        they be placed adjacently". Explict grouping, in particular, seems
+        to provide important performance improvements without less
+        implementation complexity than embedded inodes. As this changes
+        the on-disk structure, care needs to be taken, that the
+        implementation is backwards compatible.</p>
+<p><strong>Requirements</strong>:</p>
+<ul>
+  <li>Ability to read and understand foreign C code.</li>
+  <li>Ability to write C code.</li>
+  <li>Knowledge of the UFS2 filesystem.</li>
+</ul>
+      </desc>
     </idea>
 
     <idea id="mdfs">
@@ -152,23 +219,6 @@ Ideas//EN"
       </desc>
     </idea>
 
-      <idea id="cpuusage">
-        <title>CPU usage display in top</title>
-
-        <desc>
-<p>The current kernel statistics do not know how to calculate the CPU usage
-  of threaded processes.  A volunteer has to understand the current statistics
-  model, design a new statistics model and implement it.  This problem only
-  occurs with M:N threading on libpthread.</p>
-<p><strong>Requirements</strong>:</p>
-<ul>
-  <li>Ability to read and understand foreign C code.</li>
-  <li>Ability to write C code.</li>
-  <li>A good understanding of the FreeBSD SMP system.</li>
-</ul>
-        </desc>
-      </idea>
-
       <idea id="docsysctl">
         <title>Document all sysctls</title>
         <desc>
@@ -287,6 +337,7 @@ Ideas//EN"
 </ul>
 	</desc>
       </idea>
+
     <idea id="kernel-linuxemu">
       <title>Kernel support for linux device drivers</title>
 
@@ -354,7 +405,8 @@ href="http://info.iet.unipi.it/~luigi/FreeBSD/linux_bsd_kld.html">here</a>.</p>
 
 	<desc>
 <p><strong>Technical contact</strong>: <a
-  href="mailto:rookie@gufi.org">Attilio Rao</a></p>
+  href="mailto:rookie@gufi.org">Attilio Rao</a></p>,
+  <a href="mailto:jeff@FreeBSD.org">Jeff Roberson</a>
 <p>The instruction pair sysenter and sysexit can contribute to certain
   performance improvements when a syscall is made on IA32.  There is however
   no implementation of this available for FreeBSD, so a volunteer
@@ -567,7 +619,9 @@ they all need to be locked.</p>
   framework.</p>
 <p>Interested people should also have a look at <a
   href="http://lists.freebsd.org/pipermail/freebsd-geom/2007-January/001854.html">
-  a mail thread about this</a> (Ulf is not working on this).</p>
+  a mail thread about this</a> (Ulf is not working on this) and <a
+  href="http://www.freebsd.org/cgi/mid.cgi?db=irt&id=20071011022001.GC13480@gandalf.sssup.it">
+  further discussion</a> of the corresponding GEOM aspects.</p>
 <p><strong>Requirements</strong>:</p>
 <ul>
   <li>Ability to read and understand foreign C code.</li>
@@ -577,21 +631,18 @@ they all need to be locked.</p>
 	</desc>
       </idea>
 
-      <idea id="sensors">
+      <idea id="bio">
-	<title>Port OpenBSD's sensors framework</title>
+	<title>Port OpenBSD's bio framework</title>
 
 	<desc>
 <p><strong>References</strong>: <a
   href="http://www.openbsd.org/papers/bsdcan06-biosensors.pdf">Overview</a>,
-  <a href="http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/sensorsd/">
-  http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/sensorsd/</a>,
   <a href="http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/bioctl/">
   http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/bioctl/</a>, <a
   href="http://www.openbsd.org/cgi-bin/cvsweb/src/sys/scsi/safte.c">
   http://www.openbsd.org/cgi-bin/cvsweb/src/sys/scsi/safte.c</a></p>
-<p>The OpenBSD sensors framework is an unified way of handling
+<p>The OpenBSD bio framework is an unified way of handling
-  any kind of hardware sensor one can image.  A sensor driver collects
+  RAID hardware (status, config, rebuild).  It allows an
-  data from system sensors, SAS devices, harddisks, ... and allows an
   administrator to query the data with the unified management interface.</p>
 <p><strong>Requirements</strong>:</p>
 <ul>
@@ -601,6 +652,22 @@ they all need to be locked.</p>
 	</desc>
       </idea>
 
+      <idea id="sensors">
+	<title>Add support for the sensors framework to more drivers</title>
+
+	<desc>
+<p>Not much drivers make use of the sensors framework yet. Possible targets
+  which should be enhanced to use the sensors framework are ATA/SCSI (temperature,
+  write cache status, ...), GEOM (RAID status, ...), ACPI (temperature,
+  voltage, ...) and more.</p>
+<p><strong>Requirements</strong>:</p>
+<ul>
+  <li>Ability to read and understand foreign C code.</li>
+  <li>Ability to write C code.</li>
+</ul>
+	</desc>
+      </idea>
+
       <idea id="trussprocfs">
 	<title>Remove procfs dependencies</title>
 
@@ -608,10 +675,8 @@ they all need to be locked.</p>
 <p><strong>Technical contact</strong>: <a
   href="mailto:mux@FreeBSD.org">Maxime Henrion</a></p>
 <p>Someone needs to finish the support for PT_SYSCALL in the ptrace()
-  subsystem, and add support for another ptrace() command that will replace
+  subsystem and remove the need for procfs in gcore. Removing the
-  the PIOCWAIT and PIOCSTATUS ioctls of procfs (should probably be named
+  procfs(5) dependency from ps -e is also desirable.</p>
-  PT_WAIT), in order for truss(1) to be able to work without procfs(5).
-  Removing the procfs(5) dependency from ps -e is also desirable.</p>
 <p><strong>Requirements</strong>:</p>
 <ul>
   <li>C knowledge.</li>
@@ -718,28 +783,28 @@ they all need to be locked.</p>
 	</desc>
       </idea>
 
-    <idea id="sysenter">
+      <idea id="optreg">
-      <title>Sysenter for x86 syscalls.</title>
+	<title>Make optional kernel subsystems register themselves via sysctl</title>
 
 	<desc>
-<p><strong>Technical contact</strong>: <a href="mailto:jeff@FreeBSD.org">Jeff Roberson</a></p>
+<p><strong>Technical contact</strong>: <a
-
+  href="mailto:kris@FreeBSD.org">Kris Kennaway</a></p>
-<p>Sysenter is an optional feature on x86 processors that significantly reduces
+<p>Currently there is no way for e.g., a port makefile to tell whether
-the cost of calling system calls.  Implementing support for this feature would
+  things like FreeBSD 5.x compatibility are present on the system (just
-require run-time selection of syscall code, most likely using a page which is
+  installing the compat5x port is not enough, you need a kernel built
-always mapped into each process that contains the system call code.  This would
+  with COMPAT_FREEBSD5).  All such optional kernel features should
-also require some minor infrastructure in the kernel to provide the correct
+  registered themselves in a common location (e.g. sysctl MIB) so that
-entry points and stacks for kernel entry.  If there is enough time remaining
+  the userland can easily query whether a given feature is present. There
-other features could be added to this global shared page to improve performance
+  needs also be a way to spoof those values, e.g., when the ports build
-of other syscalls.</p>
+  cluster is building for older FreeBSD versions in a jail.</p>
-
 <p><strong>Requirements</strong>:</p>
 <ul>
-  <li>Solid grasp of assembly and machine state issues.</li>
+  <li>Good knowledge of C.</li>
-  <li>Some familiarity with the FreeBSD VM.</li>
+  <li>Kernel awareness.</li>
 </ul>
 	</desc>
       </idea>
+
   </category>
 
   <category>
@@ -855,12 +920,15 @@ of other syscalls.</p>
 	</desc>
       </idea>
 
-      <idea class="soc" id="suptundaemon">
+      <idea class="soc" id="magtundaemon">
-	<title>Super tunnel daemon</title>
+	<title>Magic tunnel daemon</title>
 
 	<desc>
 <p><strong>Technical contact</strong>: <a
-  href="mailto:phk@FreeBSD.org">Poul-Henning Kamp</a></p>
+  href="mailto:phk@FreeBSD.org">Poul-Henning Kamp</a>, <a
+  href="mailto:mharvan@inf.ethz.ch">Matus Harvan</a><br>
+  <strong>WIP</strong>: <a
+  href="http://wiki.freebsd.org/mtund">http://wiki.freebsd.org/mtund</a></p>
 <p>IP can be tunneled over IP, UDP, TCP, SSH, DNS, HTTP and many other
   protocols, and this means that it is often possible to get a
   connection out through a firewall, but each of these encapsulations
@@ -1262,19 +1330,23 @@ data).
       </idea>
 
       <idea id="distribaudit" class="soc">
-	<title>Distributed audit daemon</title>
+	<title>Distributed audit / log shipping daemon</title>
 
 	<desc>
 <p><strong>Technical contact</strong>: <a
-  href="mailto:rwatson@FreeBSD.org">Robert Watson</a></p>
+  href="mailto:rwatson@FreeBSD.org">Robert Watson</a><br>
-<p>Create a tool that manages per-machine audit records and submits them to
+<strong>WIP</strong>: <a
-  a central site for processing and long-term archiving/management.  Ideally
+href="http://wiki.freebsd.org/DistributedAuditDaemon">http://wiki.freebsd.org/DistributedAuditDaemon</a></p>
-  with support for SSL (or the like) so they do not travel on the wire in the
+<p>Create a tool to securely and reliably ship log files to remote hosts.
-  clear.</p>
+The main focus is to manage per-machine audit records and submit them
+to a central site for processing and long-term archiving/management.
+Ideally with support for SSL (or the like) so they do not travel on
+the wire in the clear.</p>
 <p><strong>Requirements</strong>:</p>
 <ul>
   <li>Strong (portable) C programming skills.</li>
   <li>Knowledge of the audit subsystem.</li>
+  <li>OpenSSL knowledge a plus.</li>
 </ul>
 	</desc>
       </idea>
@@ -1369,15 +1441,18 @@ New tests must be created; existing tests must be completed and updated.
   <category>
     <title>Userland / Installation Tools</title>
 
-      <idea id="bsdelftools">
+      <idea id="bsdelftools" class="soc">
 	<title>BSD-licensed ELF Tools</title>
 
 	<desc>
 <p><strong>Technical contact</strong>: <a
   href="mailto:jkoshy@FreeBSD.org">Joseph Koshy</a></p>
 <p>Create BSD-licensed versions of ELF processing tools (e.g., <strong>ld</strong>,
-  <strong>nm</strong>, <strong>as</strong> and others) using the ELF(3) and GELF(3)
+  <strong>dbx</strong>, <strong>as</strong> and others) using the ELF(3) and GELF(3)
-  API set in FreeBSD -CURRENT.</p>
+  API set in FreeBSD -CURRENT. Identify overlapping functions in those tools and
+  create a library out of the common functions. Identify parts which can be
+  generated by tools (e.g., machine code parser generators) to support our Tier-1
+  and Tier-2 architectures.</p>
 <p><strong>Requirements</strong>:</p>
 <ul>
  <li>Knowledge of C.</li>
@@ -1385,7 +1460,7 @@ New tests must be created; existing tests must be completed and updated.
 	</desc>
       </idea>
 
-      <idea id="bsdtexttools" class="soc">
+      <idea id="bsdtexttools">
 	<title>BSD-licensed Text-Processing Tools</title>
 
 	<desc>
@@ -1430,20 +1505,21 @@ New tests must be created; existing tests must be completed and updated.
 	</desc>
       </idea>
 
-      <idea id="gnomekde-freebsd-update" class="soc">
+      <idea id="kde-freebsd-update" class="soc">
-	<title>GNOME and/or KDE front-ends to the freebsd-update(8)
+	<title>KDE front-ends to the freebsd-update(8)utility</title>
-	  utility</title>
 
 	<desc>
 <p><strong>Technical contact</strong>: <a
   href="mailto:cperciva@FreeBSD.org">Colin Percival</a></p>
 <p>The freebsd-update(8) utility is used to fetch, install, and rollback
   binary updates to the FreeBSD base system.  A nice project would be to
-  develop at graphical front-end for freebsd-update(8), using the GTK and/or
+  develop at graphical front-end for freebsd-update(8), using the QT toolkit.
-  QT toolkits.</p>
+  A GTK frontend was developed as part of GSoC 2007 and exists at <a
+  href="http://developer.berlios.de/projects/facund">berlios</a>, the QT
+  frontend could maybe share common functions/classes and design ideas.</p>
 <p><strong>Requirements</strong>:</p>
 <ul>
-  <li>Experience writing GNOME and/or KDE applications</li>
+  <li>Experience writing KDE applications</li>
 </ul>
 	</desc>
       </idea>
@@ -1559,7 +1635,9 @@ clean.</p>
 
 	<desc>
 <p><strong>Technical contact</strong>: <a
-  href="mailto:brooks@FreeBSD.org">Brooks Davis</a></p>
+  href="mailto:brooks@FreeBSD.org">Brooks Davis</a><br>
+  <strong>WIP</strong>: <a
+  href="erik@cederstrand.dk">Erik Cederstrand</a></p>
 <p>The "performance tracking" entry is meant to monitor the
   performance of FreeBSD itself over the development time, e.g. someone
   makes a change to the kernel and the tracking system is able to show
@@ -1760,5 +1838,29 @@ SMP features.</p>
 </ul>
 	</desc>
       </idea>
+
+      <idea id="cron-and-atrun">  
+        <title>Improve cron(8) and atrun(8)</title>  
+
+        <desc>  
+  <p><strong>Technical contact</strong>:  
+    <a href="mailto:yar@FreeBSD.org">Yar Tikhiy</a></p>
+    
+  <p>Currently, cron(8) and atrun(8) are outdated in their implementation.
+    Here are some directions for impovement:</p>
+  <ul>
+    <li>Convert atrun(8) to using setusercontext(3) instead of creating  
+      the job context through a sequence of basic syscalls.</li>  
+    <li>Ultimately, the atrun(8) functionality could be integrated into  
+      cron(8), as it has already been done in NetBSD.
+  </ul>
+
+  <p><strong>Requirements</strong>:</p>  
+  <ul>
+    <li>Strong knowledge of C.</li>
+    <li>Understanding of PAM API.</li>
+  </ul>
+        </desc>
+     </idea> 
   </category>
 </ideas>