File:  [NetBSD Developer Wiki] / wikisrc / projects / project / kernfs-rewrite.mdwn
Revision 1.3: download - view: text, annotated - select for diffs
Mon Sep 8 17:13:34 2014 UTC (6 years, 1 month ago) by jmmv
Branches: MAIN
CVS tags: HEAD
Can't mentor these projects.  Remove myself.

    1: [[!template id=project
    2: 
    3: title="Rewrite kernfs and procfs"
    4: 
    5: contact="""
    6: [tech-kern](mailto:tech-kern@NetBSD.org),
    7: [David Holland](mailto:dholland@NetBSD.org)
    8: """
    9: 
   10: category="filesystems"
   11: difficulty="medium"
   12: duration="2-3 months"
   13: 
   14: description="""
   15: kernfs is a virtual file system that reports information about the
   16: running system, and in some cases allows adjusting this information.
   17: procfs is a virtual file system that provides information about
   18: currently running processes. Both of these file systems work by
   19: exposing virtual files containing textual data.
   20: 
   21: The current implementations of these file systems are redundant and
   22: both are non-extensible. For example, kernfs is a hardcoded table that
   23: always exposes the same set of files; there is no way to add or remove
   24: entries on the fly, and even adding new static entries is a nuisance.
   25: procfs is similarly limited; there is no way to add additional
   26: per-process data on the fly. Furthermore, the current code is not
   27: modular, not well designed, and has been a source of security bugs in
   28: the past.
   29: 
   30: We would like to have a new implementation for both of these file
   31: systems that rectifies these problems and others, as outlined below:
   32: 
   33: * kernfs and procfs should share most of their code, and in particular
   34: they should share all the code for managing lists of virtual
   35: files. They should remain separate entities, however, at least from
   36: the user perspective: community consensus is that mixing system and
   37: per-process data, as Linux always has, is ugly.
   38: 
   39: * It should be possible to add and remove entries on the fly, e.g. as
   40: modules are loaded and unloaded.
   41: 
   42: * Because userlevel programs can become dependent on the format of the
   43: virtual files (Linux has historically had compatibility problems
   44: because of this) they should if possible not have complex formats at
   45: all, and if they do the format should be clearly specifiable in some
   46: way that isn't procedural code. (This makes it easier to reason about,
   47: and harder for it to get changed by accident.)
   48: 
   49: * There is an additional interface in the kernel for retrieving and
   50: adjusting arbitrary kernel information: sysctl. Currently the sysctl
   51: code is a third completely separate mechanism, on many points
   52: redundant with kernfs and/or procfs. It is somewhat less primitive,
   53: but the current implementation is cumbersome and not especially liked.
   54: Integrating kernfs and procfs with sysctl (perhaps somewhat like the
   55: Linux sysfs) is not automatically the right design choice, but it is
   56: likely to be a good idea. At a minimum we would like to be able to
   57: have one way to handle reportable/adjustable data within the kernel,
   58: so that kernfs, procfs, and/or sysctl can be attached to any
   59: particular data element as desired.
   60: 
   61: * While most of the implementations of things like procfs and sysctl
   62: found in the wild (including the ones we currently have) work by
   63: attaching callbacks, and then writing code all over the kernel to
   64: implement the callback API, it is possible to design instead to attach
   65: data, that is, pointers to variables within the kernel, so that the
   66: kernfs/procfs or sysctl code itself takes responsibility for fetching
   67: that data. Please consider such a design strongly and pursue it if
   68: feasible, as it is much tidier. (Note that attaching data also in
   69: general requires specifying a locking model and, for writeable data,
   70: possibly a condition variable to signal on when the value changes.)
   71: 
   72: It is possible that using tmpfs as a backend for kernfs and procfs, or
   73: sharing some code with tmpfs, would simplify the implementation. It
   74: also might not. Consider this possibility, and assess the tradeoffs;
   75: do not treat it as a requirement.
   76: 
   77: Alternatively, investigate FreeBSD's pseudofs and see if this could be
   78: a useful platform for this project and base for all the file systems
   79: mentioned above.
   80: 
   81: When working on this project, it is very important to write a complete
   82: regression test suite for procfs and kernfs beforehand to ensure that the
   83: rewrites do not create incompatibilities.
   84: """
   85: ]]

CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb