Talk:Linux/Reading the Linux Kernel Sources

Latest comment: 16 years ago by ProveIt in topic Understanding the Linux Kernel ToC

This course/page is an ongoing collaboration by members of the SVLUG (Silicon Valley Linux Users Group). We're currently engaged in a weekly "Kernel Sources Study Group" (Tuesdays, 7PM at the Google campus, building 43 --- see the SVLUG events page for details).

The purpose of this page is for participants in the study group, and the users of Wikiversity at large, to propose topics for study, comment on existing comments, link to relevant materials and general teach aspiring systems programmers how to read the Linux kernel source code, and how to apply that knowlege to their own experimentation, customizations and perhaps, even inspire some to become productive kernel developers.

Naturally all contributions to these pages should respect the Wikiversity terms of service and content guidelines!

Other than that: Edit Boldly!

JimD 08:03, 14 November 2007 (UTC)Reply
Edit boldly might take some work if you don't understand the editing codes. I always feel a bit lost in a new interface. Here's a good syntax reference example page on mediawiki markup which I found after a little bit of chasing around.
Heather Stern 20:45 PST, 20 November 2007

Administrivia

edit

This discussion page can also be used as a forum for handling administrative details of the SVLUG study group. Other Linux users' groups are, of course, welcome to form their own lucky study groups and to collaborate with us to answer the questions:

  • What are the best parts of the kernel to study?
  • Where should one start reading the kernel?
  • What are the pre-requisites to studying the kernel by reading its sources?
  • What are some techniques, and exercises we can perform on the kernel sources to enhance our practical understanding of what we're reading?

Next Meeting's Agenda

edit

At the end of this last meeting some people asked for "homework" and for ideas about what we'd cover next. Given that I (User:JimD) already explained that I have no experience in teaching a class on this topic, and that I hadn't thought quite that far ahead ... I wasn't sure. So I just made something up. So far I've suggested we should look at:

  • entry.S (the assembly that forms the entry point into system calls on the x86 arch)
    • Int 0x80h handler (ultimately how Linux system calls are dispatched from user space)
    • The system call table (list of all the system calls in a given version of the kernel)
  • scheduler (one of the primarily operations of the kernel)
    • clock tick (system timer interrupt handler) (used by the scheduler, and for things like "jiffies"

As for exercises: I suggested adding a couple of printk() statements to selected parts of the kernel, init/main.c in particular; compiling the kernel with these patches, installing it and booting it. Then looking for our personal "Killroy was here" message in dmesg or the system logs. I neglected to discuss the matter of "earlyprintk" which might make this task more challenging than it sounds at first. I also suggested that a truly ambitious student might try to add a custom system call (again, just to perform a printk()) and then write a small user space C program to call their new system call and verify that their custom message appears in the kernel.

These are both "hello world" class exercises (which is appropriate for this group at this juncture). I know that there are online recipies which describe how to do this step-by-step. I woudn't consider it "cheating" to link to those from here. These are not supposed to be programming challenges but rather are to be done in the spirit of "hello world"

In the future I'm sure we'll also follow some of the recipes for creating a loadable "hello world" module, creating some sort of "echo" character device driver (perhaps one that takes each line of input written to it, perhaps truncates it, stores it in it's local state, takes a "debug" option to relay a printk() and allows one to read back the most recently written intput (the globally saved state). Other exercises would include creating /proc and/or /sysfs nodes. All of these are things which must be routine to kernel programmers and thus should be among the most elementary exercises we can propose for better understanding how to do real work.

Meanwhile my plan for the next meeting is:

  • review of the previous session (perhaps with some slides to cover the major points --- and to accommodate the video capture)
  • brief exploration of panic, shutdown and kexec (we started at "the beginning" so giving a preview of "the end" seems like a stylistic "imperative"; besides these functions are among the easiest to read).
  • reading the source to printk(); discussion of the rare cases in which it cannot be used; discussion of other debugging and logging facilities in the kernel like relayfs?
  • review of the homework/exercises: were people able to complete the simple printk stuff in init/main.c? could they see it? did anyone find info on the earlyprink stuff? Did anyone get into the system call stuff? How did they get their userspace program working?
  • new material:
    • system calls, the assembly and the C code (add a printk() into the C side of this???)
    • scheduler/timer IRQ handler
      • Note that the scheduler is a complex topic --- point to various higher level discussions about it and just glance at kernel/sched.c 2100 lines in my copy of SuSE 9 2.4.21-280).
    • timer: kernel/timer.c (about 1000 lines, including the definition and maintenance of jiffies).

I suspect that's about all we'll have time for.

Understanding the Linux Kernel ToC

edit

Just a passing comment before I head off elsewhere :-), I'm pretty sure that putting the ToC of that "Understanding the Linux Kernel" book here is a copyright violation - can you instead put a link out? This looks like a great project though - don't let me rain on the parade. :-) Cormaggio talk 13:11, 29 November 2007 (UTC)Reply

Here's a link to the same content. -- ProveIt 18:09, 29 November 2007 (UTC)Reply
Return to "Linux/Reading the Linux Kernel Sources" page.