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,
svn path=/www/; revision=30899
2007-10-14 15:48:12 +00:00 · 2007-10-14 15:48:12 +00:00 · 5c2427dc3c · 2020-12-08 03:00:23 +00:00
commit 5c2427dc3c
parent 6d4d5e9bd2
1 changed files with 172 additions and 70 deletions
--- a/en/projects/ideas/ideas.xml
+++ b/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">
-	<title>Port OpenBSD's sensors framework</title>
+      <idea id="bio">
+	<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
-  any kind of hardware sensor one can image.  A sensor driver collects
-  data from system sensors, SAS devices, harddisks, ... and allows an
+<p>The OpenBSD bio framework is an unified way of handling
+  RAID hardware (status, config, rebuild).  It 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
-  the PIOCWAIT and PIOCSTATUS ioctls of procfs (should probably be named
-  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>
+  subsystem and remove the need for procfs in gcore. 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">
-      <title>Sysenter for x86 syscalls.</title>
-
-      <desc>
-<p><strong>Technical contact</strong>: <a href="mailto:jeff@FreeBSD.org">Jeff Roberson</a></p>
-
-<p>Sysenter is an optional feature on x86 processors that significantly reduces
-the cost of calling system calls.  Implementing support for this feature would
-require run-time selection of syscall code, most likely using a page which is
-always mapped into each process that contains the system call code.  This would
-also require some minor infrastructure in the kernel to provide the correct
-entry points and stacks for kernel entry.  If there is enough time remaining
-other features could be added to this global shared page to improve performance
-of other syscalls.</p>
+      <idea id="optreg">
+	<title>Make optional kernel subsystems register themselves via sysctl</title>

+	<desc>
+<p><strong>Technical contact</strong>: <a
+  href="mailto:kris@FreeBSD.org">Kris Kennaway</a></p>
+<p>Currently there is no way for e.g., a port makefile to tell whether
+  things like FreeBSD 5.x compatibility are present on the system (just
+  installing the compat5x port is not enough, you need a kernel built
+  with COMPAT_FREEBSD5).  All such optional kernel features should
+  registered themselves in a common location (e.g. sysctl MIB) so that
+  the userland can easily query whether a given feature is present. There
+  needs also be a way to spoof those values, e.g., when the ports build
+  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>Some familiarity with the FreeBSD VM.</li>
+  <li>Good knowledge of C.</li>
+  <li>Kernel awareness.</li>
 </ul>
-      </desc>
-    </idea>
+	</desc>
+      </idea>
+
  </category>

  <category>
@ -855,12 +920,15 @@ of other syscalls.</p>
 	</desc>
      </idea>

-      <idea class="soc" id="suptundaemon">
-	<title>Super tunnel daemon</title>
+      <idea class="soc" id="magtundaemon">
+	<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>
-<p>Create a tool that manages per-machine audit records and submits 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>
+  href="mailto:rwatson@FreeBSD.org">Robert Watson</a><br>
+<strong>WIP</strong>: <a
+href="http://wiki.freebsd.org/DistributedAuditDaemon">http://wiki.freebsd.org/DistributedAuditDaemon</a></p>
+<p>Create a tool to securely and reliably ship log files to remote hosts.
+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)
-  API set in FreeBSD -CURRENT.</p>
+  <strong>dbx</strong>, <strong>as</strong> and others) using the ELF(3) and GELF(3)
+  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">
-	<title>GNOME and/or KDE front-ends to the freebsd-update(8)
-	  utility</title>
+      <idea id="kde-freebsd-update" class="soc">
+	<title>KDE front-ends to the freebsd-update(8)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
-  QT toolkits.</p>
+  develop at graphical front-end for freebsd-update(8), using the QT toolkit.
+  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>