Re: hacking kernel

Fred K Ollinger <[email protected]> Mon, 24 Feb 2003 13:27:25 -0500 (EST)
Newsgroups gmane.linux.redhat.axp.kernel
Message-ID <[email protected]>
>  The best refrence is the source code itself. I think a few publishers
> have printed
> books with the kernel fully broke down. Try barnes and noble.
>
> In regards to services, services are not an function of the kernel they are
> user level programs.

I agree with the above poster. I have a few more suggestions. These are
not to insult your intelligence as I can't possibly know what you know so
skip it if it's too basic. Note, you should be doing a lot of this stuff
simultaneously, though the earliest ones are important before you go on to
later steps.

1. You must know unix before you can even hope to hack the kernel as this
will save lots of time. 'grep' is really handy.

2. Learn and editor: emacs, vi or something else, doesn't matter as long
as you can use it efficiently.

3. You won't get far if you don't know c especially pointers as well as
unix function calls. I would start mastering c programs which are easy to
recover from before I start hacking the kernel.

4. I would start compiling and running first normal kernels, then bleeding
edge ones. Get a knack for menuconfig, this will help a lot when you
actually go into the kernel tree. Also reading kernel mailing lists daily
along w/ bug reports that should coorespond to troubles (smile) that you
are having w/ bleeding edge kernel. I have a test box to run bleeding edge
kernels on as well as other beta sw.

5. Learn to apply patches to the kernel and recompile. Now you can for the
bleeding edge kernel and make your own w/ patches. Also, manually make
changes as suggested from the kernel mailing list. Now you are really
getting confident.

6. Now you are ready to dive into the source. Best way is to look around
the tree especially if you have a book on the linux kernel. Get a lay of
the land recall all that you learned from menuconfig.

7. Now you are ready for a project. Try to fix a bug on the bleeding edge
kernel if the compile fails. Or you could go in and grep for bugs as given
on the kernel janitors list:

http://kerneljanitors.org/

Use cvs (you should know this by now) to check out the latest todo list
and start on something simple. I'm trying to replace all instances of
strtok w/ strsep, and it's harder for me than I thought. Guess I should go
work on step #3. :)

Welcome and good luck.

Fred Ollinger