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.

    Kernel001WalkThrough

    FileSystemAnalysis

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.

[gdonald] http://www.tamacom.com/tour/kernel/linux2/ seems to be a good source browser.

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..

Read more: CompleteNewbiesClickHere
QR:

Posted via email from Jasper-net