help in the MM Area of the Linux Kernel

From: valdis.kletnieks@vt.edu (valdis.kletnieks at vt.edu)
To: kernelnewbies@lists.kernelnewbies.org
Subject: help in the MM Area of the Linux Kernel
Date: Fri, 06 Oct 2017 12:34:30 -0400	[thread overview]
Message-ID: <5997.1507307670@turing-police.cc.vt.edu> (raw)
In-Reply-To: <1507220048.1800.7.camel@icloud.com>

On Thu, 05 Oct 2017 18:14:08 +0200, Damian Tometzki said:

> i'am intrested in helping and Bug Fixing in the mm area of the linux
> kernel.?
>
> For driver development is it clear check in the staging area the
> TODO's.?
>
> And what is the process for other areas of the kernel for example mm
> (Memory management X86) ??

Rule 1 of kernel hacking:  Not every mechanic gets to work on Formula 1
engines.

For mm, you'll probably need to show some expertise in other kernel areas,
*plus* have a deep understanding of memory management theory. That code has
already been worked over by multiple professionals, which means pretty much all
the easy stuff has already been done.

Oh, and you're probably going to also need knowledge of the kernel
instrumentation - perf, tracepoints, and friends.

If you manage to find an actual bug in that code, it is most likely going to be
some weird corner case, and *much* MM clue will be required to fix it without
breaking some *other* more common corner case.  Remember that the same code has
to Do The Right Thing on everything from an embedded system with 32M of RAM and
only one major process running, to large mainframe class boxes with a terabyte
of RAM, a large Oracle instance, and several hundred Apache / Tomcat / etc
processes flickering in and out of existence, to multi-terabyte systems running
HPC (where the use of RDMA over Infiniband by things like MPI creates
challenges due to a *lot* of locked pages...)

Your best bet?  Find a replicable corner case (this may require access to a
variety of systems), create a test-case that can cause the corner case on
demand.  Figure out what the mm code is doing, and how it could do it better.
Write a patch, test, and then double-check on other systems that you didn't
cause a regression.  Submit the patch.

Good luck. :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20171006/0ce54c2d/attachment.bin 