Annotation of wikisrc/projects/project/kernfs-rewrite.mdwn, revision 1.2
1.1 jmmv 1: [[!template id=project
3: title="Rewrite kernfs and procfs"
1.2 ! dholland 6: [tech-kern](mailto:tech-kern@NetBSD.org),
! 7: [David Holland](mailto:dholland@NetBSD.org)
1.1 jmmv 8: """
11: [Julio Merino](mailto:jmmv@NetBSD.org)
16: duration="2-3 months"
1.2 ! dholland 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.
1.1 jmmv 84:
1.2 ! dholland 85: When working on this project, it is very important to write a complete
1.1 jmmv 86: regression test suite for procfs and kernfs beforehand to ensure that the
1.2 ! dholland 87: rewrites do not create incompatibilities.
1.1 jmmv 88: """
CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb