docs/developer/researchprojectspage/index.mdwn

   1 # DragonFly Projects
   2
   3 This is an off-shoot of the main [[ProjectsPage|docs/developer/ProjectsPage]] intended to house more bizarre projects and concepts. It should be noted that if you decide to implement one of these projects, even if you do an amazing job, it is entirely likely that it will never be committed to the main source repository. If you intend your work to be committed, please discuss your plans with the DragonFly community at large on the public mailing lists before you make a significant investment in your work.
   4
   5 Please feel free to add projects to this page, or annotate existing project ideas with your own thoughts.
   6
   7 [[!toc levels=3 ]]
   8
   9 ## Kernel projects
  10
  11 ### Code generation hooks in the build system
  12 * Well defined kernel build mechanisms for code generation
  13 * This will require discussion
  14
  15 ### On-disk / Over-the-wire structure codegen + CAPS
  16 * Somewhat analogous to google protocol buffers / etc.
  17 * Take a normalized definition of data, metadata or an operation and generate a structure, serialization routines and accessor routines for it/them
  18 * Must be able to generate structs binary compatible with existing on-disk formats (including warts)
  19 * Should magically create formats that are 32/64bit agnostic OR fixup serializers/unserializers
  20 * Accessor routines and thread safety? Do we make you hang these objects somewhere that you store your synchronization objects or allow you to include them?
  21 * Optional versioning?
  22 * Potential uses: ... HAMMER, UFS, HAMMER mirror streams, message passing, ...
  23 * CAPS (DragonFly's message passing system, which exists but is not functional at the time of this writing) has an over-the-wire format with serialization/deserialization. This codegeneration serialization solution should be amenable to the purposes of CAPS or whatever future message passing infrastructure might be implemented in DragonFly.
  24 * CAPS References: [1](http://www.shiningsilence.com/dbsdlog/2003/11/25/139.html#more-139) [2](http://www.shiningsilence.com/dbsdlog/2004/03/07/293.html#more-293) [3](http://www.shiningsilence.com/dbsdlog/2004/04/24/365.html#more-365)
  25 * Messaging References: [1](http://leaf.dragonflybsd.org/mailarchive/commits/2006-07/msg00172.html)
  26
  27 ### Asynchronous system call framework
  28 * Probably best implemented as a message passing interface to kernel pass messages in, threads pick them up and execute, return through kevent notifications
  29 * Would require a well-considered proposal
  30
  31 ### Kernel VIRTUAL MACHINE
  32 * opcode vm in kernel for various purposes? What could be accomplished with this?
  33
  34 ### Allocator meta-madness
  35 * Modern general purpose allocators usually use 2-3 or more different allocation strategies for differently sized allocations.
  36 * Modern general purpose allocators try _very hard_ to optimize for all circumstances, many allocations/frees, many allocations/few frees, short-running applications, long-running applications, internal and external fragmentation, etc.
  37 * It may be possible to develop a framework by which simple allocators are matched up to programs based on their allocation behavior that performs better all-around than complex modern general purpose allocators using a variety of simple allocators.
  38 * Profile programs memory allocation and usage behavior to determine an optimal allocator type to use.
  39 * Short-running applications will simply want something really cheap to setup, etc.
  40 * Dispatch to the most efficient allocator implementation on future execution.
  41 * Perhaps allocators can export their size range and a series of flags indicating what they are suited for, and the profiling could build a set of flags based on application behavior.
  42 * This could be done per-thread in a lockless fashion and coalesced with weights atexit().
  43 * The scope of this work might be appropriate for a PhD or Masters thesis.
  44 * Such a framework likely would not replace the base system allocator but if it were lightweight enough could possibly augment (and/or incorporate) it.
  45 * For applications definitely known to work better under some configuration, flags could be seeded and pkgsrc could link those apps against the best alternative meta-allocator.
  46
  47 ### Opt-in userland thread scheduler
  48 * A great deal of research has been done on this topic, implementations exist for other operating systems.
  49 * References: [1](http://leaf.dragonflybsd.org/mailarchive/kernel/2007-03/msg00038.html)