Clean

  • Patch name includes "create" if it creates a new file.
  • Patch name includes "breakup" if it should really be two (2) or more patches.
  • Patch name includes "one-way" if it has effects even when the CONFIG_OPENMOSIX option is turned off. This excludes the config system itself, header includes, and new files.
  • Patch name includes "one-way" if it creates a header file that is not dependent on the CONFIG_OPENMOSIX option.
  • Patch name includes "broken" if it is "obviously" broken. Includes, but is not limited to, code marked "STUB", "FIXME", or "XXX" or incomplete code.
  • Patch name includes "cleanup" if it:
    • contains dead or 2.4-only code
    • has incorrect whitespace
    • has poor variable names
    • is missing comments in assembly.
    • is missing /* CONFIG_OPTION */ after a #endif matching a #ifdef CONFIG_OPTION
  • Patch name includes "final" if it is the last patch to touch some file.
  • Comments are correct, that is they reflect the current patch. Rewrite as needed.
  • note in commentary if:
    • a function is only called from a few places
    • function fails to check passed in pointers against NULL.
    • function fails to perform cleanup in case of errors.
    • Function uses printk() directly
    • Function contains STUB, FIXME, or incomplete code. Don't forget to rename to patch to include "broken".
    • Function invokes OMBUG with a prefix on its output. OMBUG() adds the "[OMBUG] " prefix to it's output, the caller does not need to provide a similar prefix.
  • Patch is classified into classes (see bottom of page) in the comments in the series file and commentary.

Patches believed to be CLEAN are placed in the linuxpmi/clean directory.

Silver

  • Must be CLEAN.
  • Single-duty patches. That is, no patch with "breakup" in the name can be silver.
  • (Mostly) clean patches. All the changes implied by "cleanup" in the name of the patch need to be complete. Exception: dead code does not (yet) have to be removed.
    • Assembly code has a high comment-to-code ratio. Assembly is becoming a lost art and needs more documentation than other code.
    • "#ifdef CONFIG_OPTION" has a matching "#endif /* CONFIG_OPTION */".
  • Tag patches by duty area.
    • "i386", "x86_64", or "ppc" in the name for architecture-specific patches.
    • "remote" or "local" based on where the patch changes behavior.
    • "kcomd", "config", "procfs".
    • "ksocket" for kernel modifications so that we can perform normal socket operations in-kernel.
  • All functions have kdoc.
  • Header dependencies commented. each header we add should have a list of what its including in the comments above it.
  • Use EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL after verifying GPL license in header.
  • Replace printk() calls with appropriate OM_DEBUG macro or remove entirely.
  • OMBUG() text should be unique. You should be able to grep the source for the message and discover the line that reported the error.
  • Patches are sequenced to maximize locality. E.g. patches to the same file will be as close to one another as possible.

Patches believed to be SILVER are placed in the linuxpmi/silver directory.

Gold

  • Must be SILVER.
  • All newly created files will have a header describing it's purpose and why the functions defined in the file are there and not somewhere else.
  • kcom.h is included before prototype.h
  • If code is removed by a later patch, change both patches to remove the code in the earlier one only.
  • All includes comment what functions/macros/variables are used from them.
  • All functions comment what context they are called in, specifically any assumption about the caller and kernel state they make.
  • All functions comment wether they are preemptable or not. in an atomic state? calling schedule?
  • Each error condition should print an error message. Any function that can return error codes should perform minimalist error recovery.
  • All messages are printed though macros (e.g. OMDEBUG, OMBUG, etc.) instead of direct invocation.
  • No resource leaks.
  • Variables will follow kernel naming conventions.
  • Function that manipulate lists will use proper spinlocking.
  • mm->realusers is manipulated atomically.
  • All defines added to header will be commented.
  • Patches will comply with Kernel Precedents, Security Rules, and Userspace Interfacing Rules.
  • Kernel threads should not directly lock spinlocks, but employ helper functions to do the locking.
  • If the CONFIG_OPENMOSIX is turned off, the patches do nothing.

Patches believed to be GOLD are placed in the linuxpmi/gold directory.

Platinum

  • Must be GOLD.
  • Patches are ordered so that dependencies are applied before the patches that depend on them.
  • Before a header is included, there's a comment explaining what variables/functions/macros are required from that header.
  • Merge patches that modify the same file into a single patch, without violating the single-duty patch guideline above.
  • Make sure the correct file is being patched.
  • Locate and preferably merge with it's "twin", the patch that handles the other (local vs. remote) side.
  • Locate and preferable merge with other patches that are closely related and preforming the same duty.
  • If a function performs argument checking or acquires kernel resources and does "real" work, break that function along those lines.
  • Drop dead code.

Patches believed to be PLAT are placed in the linuxpmi/plat directory.

Classes

Class Description
config part of the Kconfig system, that the kernel uses to build
local adds functionality that is only accessable locally
omremote required to allow a process to execute on another node
omremotefile required to allow a process executing on another node remote file access
omremotedentry required to allow a process executing on another node remote dentry access
omlocal required to allow other node's processes to run on this node