File:  [NetBSD Developer Wiki] / wikisrc / projects / project / kernfs-rewrite.mdwn
Revision 1.2: download - view: text, annotated - select for diffs
Thu Feb 27 05:59:11 2014 UTC (6 years, 7 months ago) by dholland
Branches: MAIN
CVS tags: HEAD
Edit the text; rework parts of it. There are some issues that the
original author didn't think of, such as integrating with sysctl.

Also suggest an implementation that uses pointers to kernel data
rather than callbacks; it takes a bit more work but it's much tidier
and much less invasive. I have BSD-licensed prior art, too, if anyone
wants to look at it; unfortunately it's not really suitable for NetBSD
without a rewrite.

Make myself a contact. (Not a mentor, as regardless of this year's
issues in general I don't have time to GSOC mentor.)

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

CVSweb for NetBSD wikisrc <> software: FreeBSD-CVSweb