Diff for /wikisrc/projects/project/kernfs-rewrite.mdwn between versions 1.1 and 1.2

version 1.1, 2011/11/06 19:58:46 version 1.2, 2014/02/27 05:59:11
Line 3 Line 3
 title="Rewrite kernfs and procfs"  title="Rewrite kernfs and procfs"
 contact="""  contact="""
 [tech-kern](mailto:tech-kern@NetBSD.org)  [tech-kern](mailto:tech-kern@NetBSD.org),
   [David Holland](mailto:dholland@NetBSD.org)
 """  """
 mentors="""  mentors="""
Line 15  difficulty="medium" Line 16  difficulty="medium"
 duration="2-3 months"  duration="2-3 months"
 description="""  description="""
 kernfs is a virtual file system that provides the user several information about  kernfs is a virtual file system that reports information about the
 the current system and, in some cases, allows him to configure some aspects of  running system, and in some cases allows adjusting this information.
 the kernel through those virtual files.  procfs is another virtual file system  procfs is a virtual file system that provides information about
 that provides information about the currently running processes.  currently running processes. Both of these file systems work by
   exposing virtual files containing textual data.
 These two file systems are written in a non-extensible way.  For example, kernfs  
 is built on a hardcoded table that always exposes the same set of files; there  The current implementations of these file systems are redundant and
 is no way for other system areas to add or remove entries from the kernfs  both are non-extensible. For example, kernfs is a hardcoded table that
 contents.  procfs has similar issues as someone might think of a subsystem that  always exposes the same set of files; there is no way to add or remove
 could benefit from attaching information of its own to each running process.  entries on the fly, and even adding new static entries is a nuisance.
 The current code is not modular, not well-designed and, as time has shown, there  procfs is similarly limited; there is no way to add additional
 probably remain serious security bugs in them.  per-process data on the fly. Furthermore, the current code is not
   modular, not well designed, and has been a source of security bugs in
 Linux exposes some APIs that abstract procfs' contents and allow external code  the past.
 to manage its entries by adding or removing files and/ or directories.  This is  
 a very interesting feature when writing loadable kernel modules as they can use  We would like to have a new implementation for both of these file
 this virtual file system to provide a way of interaction with the end user.  systems that rectifies these problems and others, as outlined below:
 NetBSD could benefit of similar APIs for both kernfs and procfs.  This project  * kernfs and procfs should share most of their code, and in particular
 would consist on adding these APIs, which most likely requires (or suggests) a  they should share all the code for managing lists of virtual
 full rewrite of these file systems.  The developer should keep in mind the  files. They should remain separate entities, however, at least from
 distinction between the two to avoid having a procfs similar to the one in  the user perspective: community consensus is that mixing system and
 Linux, which mixes system configuration and process management.  per-process data, as Linux always has, is ugly.
 In order to keep the new implementations simple, the developer should  * It should be possible to add and remove entries on the fly, e.g. as
 investigate the possibility of using tmpfs as a backend for kernfs and procfs.  modules are loaded and unloaded.
 With some changes, one could create a kernel "library" that allowed the creation  
 of virtual file systems with few code.  For example, it's unlikely that the  * Because userlevel programs can become dependent on the format of the
 directory management routines will change among the three file systems, so the  virtual files (Linux has historically had compatibility problems
 code from tmpfs should be reused.  Similarly other features should be reusable,  because of this) they should if possible not have complex formats at
 making procfs's and kernfs's code a lot simpler than currently is.  all, and if they do the format should be clearly specifiable in some
   way that isn't procedural code. (This makes it easier to reason about,
   and harder for it to get changed by accident.)
   * There is an additional interface in the kernel for retrieving and
   adjusting arbitrary kernel information: sysctl. Currently the sysctl
   code is a third completely separate mechanism, on many points
   redundant with kernfs and/or procfs. It is somewhat less primitive,
   but the current implementation is cumbersome and not especially liked.
   Integrating kernfs and procfs with sysctl (perhaps somewhat like the
   Linux sysfs) is not automatically the right design choice, but it is
   likely to be a good idea. At a minimum we would like to be able to
   have one way to handle reportable/adjustable data within the kernel,
   so that kernfs, procfs, and/or sysctl can be attached to any
   particular data element as desired.
   * While most of the implementations of things like procfs and sysctl
   found in the wild (including the ones we currently have) work by
   attaching callbacks, and then writing code all over the kernel to
   implement the callback API, it is possible to design instead to attach
   data, that is, pointers to variables within the kernel, so that the
   kernfs/procfs or sysctl code itself takes responsibility for fetching
   that data. Please consider such a design strongly and pursue it if
   feasible, as it is much tidier. (Note that attaching data also in
   general requires specifying a locking model and, for writeable data,
   possibly a condition variable to signal on when the value changes.)
   It is possible that using tmpfs as a backend for kernfs and procfs, or
   sharing some code with tmpfs, would simplify the implementation. It
   also might not. Consider this possibility, and assess the tradeoffs;
   do not treat it as a requirement.
   Alternatively, investigate FreeBSD's pseudofs and see if this could be
   a useful platform for this project and base for all the file systems
   mentioned above.
 Alternatively, investigate FreeBSD's pseudofs and see if this could be a useful  When working on this project, it is very important to write a complete
 for this project and base for all the file systems mentioned above.  
 When working in this project, it is very important to write a complete  
 regression test suite for procfs and kernfs beforehand to ensure that the  regression test suite for procfs and kernfs beforehand to ensure that the
 rewrites do not add incompatibilities.  rewrites do not create incompatibilities.
 """  """
 ]]  ]]

Removed from v.1.1  
changed lines
  Added in v.1.2

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