Annotation of wikisrc/projects/project/kernfs-rewrite.mdwn, revision 1.4
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: """
12: duration="2-3 months"
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,
1.4 ! dholland 70: possibly a condition variable to signal on when the value changes and/or a mechanism for checking new values for validity.)
1.2 dholland 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.
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: """
CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb