Welcome to NYCU CSIT Mirror site

Linux Kernel Trivial Patch Monkey Page

Linux Kernel Trivial Patch Monkey Page

Trivial Patch Collections

Trivial megapatch for v2.4: trivial-patch-2.4.gz or trivial-patch-2.4.bz2.

Trivial megapatch for v2.6: trivial-patch-2.6.gz or trivial-patch-2.6.bz2.

What is this?

I set up the Trivial Patch Monkey (trivial at rustcorp.com.au) so people had somewhere to send small patches that might otherwise get lost. You can either just send your patch to trivial (for example, if you are the maintainer of the code you are patching), or you can send it to the maintainer/list and cc: trivial so that it gets some review and doesn't get lost.

What is an appropriate patch for trivial, and what happens?

  1. Trivial patches must qualify for one of the following to be accepted:
    • Spelling fixes in documentation
    • Spelling fixes which could break grep(1).
    • Warning fixes (cluttering with useless warnings is bad)
    • Compilation fixes (only if they are actually correct)
    • Runtime fixes (only if they actually fix things)
    • Removing use of deprecated functions/macros (eg. check_region).
    • Contact detail and documentation fixes
    • Non-portable code replaced by portable code (even in arch-specific, since people copy, as long as it's trivial)
    • Any fix by the author/maintainer of the file. (ie. patch monkey in re-transmission mode)
    They must also be "trivial" by my definition of trivial. Best patches contain enough context for me to judge without opening the file (diff -C -u is your friend).

    NOTE: This means I'll only take whitespace/indentation fixes from the author or maintainer.

  2. I actually read the patches, so don't expect real-time response.
  3. The patch will not be forwarded to anyone until a new kernel has been released after I receive the patch, *unless* noone else is sent the patch. So if you cc: the trivial patch monkey, it'll only be forwarded from there if it doesn't make the next kernel.
  4. The first time the patch is forwarded, it will be sent to the author and/or maintainer. If they say they've included it in their tree, no more forwards will occur (modulo some timeout eventually). If they NAK it, the patch will be closed. Otherwise, the patch will be sent directly to Linus or Marcelo on future forwards (the maintainer will still be cc'd).

How should I send my patch?

  1. Please provide one patch per email, even if it means 50 emails.
  2. Make sure your diffs Unified diffs, from the old file to the new, and are -p1 compliant, ie: 
    	  +++ linux/drivers/net/foo.c
  3. MIME is fine.

Trivial Patch Status
Author Subject
Rusty Trivial Russell. (Yes, you can reach me via kernel org. No spam please.).