[NetBSD Developer Wiki]
- view: text
- select for diffs
Thu Feb 27 05:59:11 2014 UTC
(6 years, 7 months ago) by dholland
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"
7: [David Holland](mailto:dholland@NetBSD.org)
11: [Julio Merino](mailto:jmmv@NetBSD.org)
16: duration="2-3 months"
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.
CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb