Ideas on how to get into kernel hacking
1. Look at a very old, very simple kernel.
First advice I got when I entered #kernelnewbies a year ago, was to download kernel version 0.0.1. It's a good start for someone who doesn't know jack about kernels, and wants to see a very basic one. [Dan Aloni]
[Sherilyn] The 0.01 kernel downloads to about 10000 lines of C and assembler, which is fairly manageable. Note that it's a barely functional UNIX with tons of bugs, but that doesn't stop it being useful if (like me) you just want to get a quick snapshot of the way in which a UNIX system boots up and starts executing processes, and a broad, uncluttered picture of the kernel system call API. I have written the following Wiki pages which may be of use as an introduction to kernel programming. Please add any corrections, etc.
2. Follow the source code of the bootstrapping process.
[Richard Ureña] What I'm doing: with the current 2.4.x kernel, I am following the bootstrapping process, taking notes as I go along. Starting with bootsect.S (i386) and following a fair amount of the assembler code (ouch!) through setup.S, head.S (with a quick glance at video.S) and on to start_kernel(), following the initialization routines one or two levels deep. Currently I've finished reading mem_init()
->[cskim] what I'd like to do: Just like you, I'd like to start hacking the 2.4.x kernel from the bootstrapping process. If your job, taking notes as you go along, is available to me or any newbies who wants to start hacking the kernel like your method, that will help me very much. If it is availble, how can I get the your job? ftp?, BBS board? or e-mail?
It's been slow going, largely because of a) lack of time, and b) also because initially every cross-reference, helper functions, etc. etc. are all brand new to me. I expect that things in b) will move more quickly as I become more familiar with this stuff.
What I expect to gain from this: a good understanding of how things work at the lowest possible level.
- Is this approach completely stupid and a waste of time, or is there a faster way to get up to achieve that goal?
[mazzoo] I use the kernel browser from http://lxr.linux.no/source/ a lot. It has excellent cross-links for most symbols etc.
3. Add modifications, or fix bugs, that interest you.
[davej] This is almost exactly how i got started. I got hold of an IDT Winchip CPU, and found Linux didn't recognise it, or support any of its features. The kernel booted, but the BIOS left features disabled, and /proc/cpuinfo had no idea what to make of it. I spent a day or so figuring out how arch/i386/kernel/setup.c worked, and added the support necessary for the Winchip. In the months that followed, I got various other CPU features added, more errata worked around etc, and ended up rewriting big chunks of setup.c. As time went on, this spilled over into fixing up things in mtrr.c, msr.c and other associated CPU-level 'drivers'. I learnt a lot from it, and it's still an area of the kernel I enjoy working on. These days, setup.c is pretty much maintained by H.Peter Anvin and myself. A nice project for someone wanting to cut their teeth in a similar fashion would be to backport a lot of the fixes/errata workarounds/cpu recognition to the 2.0 kernel. (I've got 2.2 covered). 2.0.40 is still scheduled for release later this year aparently, and has no idea what to make of Athlons, Durons, Celerons, P4's etc..
4. Use the Kernel Mailing List (lkml).
What I did...and maybe you could try
Subscribe to the Kernel Mailing list at http://vger.kernel.org/. A digest is available at Dell's website if you don't want hundreds of e-mails a day. Alternatively you could go to the kernel traffic website (summary of the kernel mailing list). Read the FAQ and search the net for an answer before submitting to the list. About 4,000 - 5,000 will get your e-mail and if it's dumb you'll hear about it.BR
Get the latest version of the kernel and compile it.BR
Look at patches submitted to the kernel list and look at what they do/fix.BR
Stay up to date on the latest kernel changes and releases (join the kernel kernel announce list at http://vger.kernel.org/).[[BR]]
After being part of the Kernel scene for a bit find a part that interests you and study it.BR
Try to find bugs.BR
Think of anything you can do to make it better w/o messing up something else.BR
Submit your code.BR
5. Read and write
- Understanding the Linux Kernel from O'Reilly
- IA-32 Intel Architecture Software Developer's Manual Volume 3: System Programming guide.
- Maybe skim Volumes 1 and 2.
- Using this information, start writing your own simple boot loader and kernel. Try and get the processor into 32 bit protected mode, and write Hello World to the Video Memory.
- Better, if you are not too interested in assembly and the ancient real mode x86 - use GRUB as your boot loader. Grub takes care of a lot of frustrating cruft that just isn't very valuable to know. You can concentrate on writing your toy kernel mostly in C, with just a little inline assembly here and there. See the GRUB manual for lots of good info.
Back to KernelHacking.