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

1.1       jmmv        1: [[!template id=project
                      2: 
                      3: title="Rewrite kernfs and procfs"
                      4: 
                      5: contact="""
1.2     ! dholland    6: [tech-kern](mailto:tech-kern@NetBSD.org),
        !             7: [David Holland](mailto:dholland@NetBSD.org)
1.1       jmmv        8: """
                      9: 
                     10: mentors="""
                     11: [Julio Merino](mailto:jmmv@NetBSD.org)
                     12: """
                     13: 
                     14: category="filesystems"
                     15: difficulty="medium"
                     16: duration="2-3 months"
                     17: 
                     18: description="""
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.
        !            24: 
        !            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.
        !            33: 
        !            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:
        !            36: 
        !            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.
        !            42: 
        !            43: * It should be possible to add and remove entries on the fly, e.g. as
        !            44: modules are loaded and unloaded.
        !            45: 
        !            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.)
        !            52: 
        !            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.
        !            64: 
        !            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.)
        !            75: 
        !            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.
        !            80: 
        !            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: """
                     89: ]]

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