Annotation of wikisrc/projects/project/kernfs-rewrite.mdwn, revision 1.3

1.1       jmmv        1: [[!template id=project
                      3: title="Rewrite kernfs and procfs"
                      5: contact="""
1.2       dholland    6: [tech-kern](,
                      7: [David Holland](
1.1       jmmv        8: """
                     10: category="filesystems"
                     11: difficulty="medium"
                     12: duration="2-3 months"
                     14: description="""
1.2       dholland   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.
                     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.
                     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:
                     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.
                     39: * It should be possible to add and remove entries on the fly, e.g. as
                     40: modules are loaded and unloaded.
                     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.)
                     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.
                     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.)
                     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.
                     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.
1.1       jmmv       80: 
1.2       dholland   81: When working on this project, it is very important to write a complete
1.1       jmmv       82: regression test suite for procfs and kernfs beforehand to ensure that the
1.2       dholland   83: rewrites do not create incompatibilities.
1.1       jmmv       84: """
                     85: ]]

CVSweb for NetBSD wikisrc <> software: FreeBSD-CVSweb