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