Ext4 Contributing

OBSOLETE CONTENT

This wiki has been archived and the content is no longer updated.
For latest ext4 documentation, see Kernel Docs.

Overview

This page summarizes the process of contributing code to the ext4 kernel driver or to e2fsprogs.

e2fsprogs

1. Clone the e2fsprogs git repo (git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git)
2. (Optional) if you have a new enough gcc (4.8?), try configuring with ./configure --enable-gcov for automatic code coverage reporting.
3. Make your code modifications as you see fit.
4. Write some functional tests (see tests/ for examples, and use make testnew to generate a new test) if you're writing new code.
5. Run the regression suite: make check. If you enabled gcov in step 2, run make coverage.txt to generate the coverage report.
6. Wash, rinse, repeat until your code does what you want it to do.
7. Static analysis, part 1: Run make gcc-wall-new to compile with all GCC warnings enabled.
8. Static analysis, part 2: Run make clean; make C=1 to check your code against sparse.
9. Regression tests: Run cd tests/; make test_script; ./test_script --valgrind-leakcheck to look for memory leaks.
10. When writing up your patches, please follow the guidelines in https://www.kernel.org/doc/Documentation/SubmittingPatches
11. Run your patches through the kernel's style checker in scripts/checkpatch.pl.
12. Send patches to the mailing list linux-ext4 at vger.kernel.org.

While Eric Sandeen and Ted T'so occasionally upload code snapshots to Coverity as an additional checkpoint, these steps can be performed by any developer.

ext4 kernel

1. Clone the kernel git repo (git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git)
2. Make your code modifications as you see fit.
3. Build your code with static analysis enabled: make C=1. Please fix the things it complains about, or discuss with the sparse developers if you think you have a false-positive.
4. Run the appropriate testing suites against the kernel. For functional testing of ext4, run xfstests (http://xfs.org/index.php/Getting_the_latest_source_code). The tests in generic/, shared/, and ext4/ should all pass. For interface testing of ext4, also consider running LTP (http://ltp.sourceforge.net/).
5. Wash, rinse, repeat until your code does what you want it to do.
6. When writing up your patches, please follow the guidelines in https://www.kernel.org/doc/Documentation/SubmittingPatchesn
7. Run your patches through the kernel's style checker in scripts/checkpatch.pl.
8. Send patches to the mailing list linux-ext4 at vger.kernel.org.