[svlug] Please read and respond - I suggest postponing 1st code walk-thru mtg

Darlene Wallach freepalestin at dslextreme.com
Sat Nov 3 17:30:48 PST 2007


I have a concern that we are not ready to start
the Linux kernel code walk-through meetings. I
want to make sure we are putting the very generous
offer of Google to host us to the best possible use.
I also want to make sure we are making the best use
of our time to participate and have our meetings

I have not seen a syllabus/curriculum for the
upcoming Linux kernel code walk-through.

I assert we should have a suggested
syllabus/curriculum, which specific kernel code
we will use, a specific editor, etc. so that
everyone is looking at the same code and seeing
the same line numbers - this would seem to especially
benefit people who will view via the video. What
else should be common for everyone? What am I not

I suggest we have a link on svlug.org which lists
everything so that people who want to participate
can look there to see where we are - what we have
covered, what we plan on covering (in case they
want to come to a specific meeting).

Are there people interested in the code walk-through
that want to propose different aspects? If different
people take on the tasks it won't all land in the
hands of one person. I assume most people have day
jobs, family/relationship responsibilities. So most
people will not have a lot of extra time on their

Are there people who concur with my assertions and

Are there people who offer to take on doing some of
the work?
  - which specific kernel should we use

Here is what I have seen posted in regards to what
to cover/do:

Srihari Raghavan
    Sort of a junior-level Linux experience guy here.  I was wondering, 
if there is currently, and if not, is there any interest...in having 
intensive source code walk-through sessions for Linux kernel.

     To get an idea of what I am talking about, some thing along the 
lines of:

and in another post Srihari wrote:

My 2c w.r.t suggestions...

     a. Filming it for youtube is great, but it could be worthwhile to 
do it after a few sessions, as that would give us time to make the 
sessions more structured, settle down on topics, identify ways of 
conducting these sessions etc.,

     b. Regarding topics, these are some thoughts...IMHO.  In general, 
it would be good to understand "Design Patterns in Kernel 
software"...how does Linux solve (in terms of in-depth data structures, 
algorithms) the many well known aspects of OS/kernels....some examples:
         1. How does Linux work with diff. HW...essentially kernel 
startup, machine dependent/independent code, working in a small 
processing/memory footprint device, logical volumes etc.,
         2. Process creation/handling, system calls, interrupts, 
interrupt handlers, BH handlers, kernel synchronization methods etc.,
         3. Scheduler - how does it handle interactive vs. CPU intensive 
processes..O(1) scheduler using priority queues/red-black trees, process 
synchronization etc.,
         4. Memory handling - slab allocator and other types, virtual 
memory, memory alloc/dealloc tracking, handling leaks, 
paging/segmentation etc.,
         5. Linux kobjects, sysfs, modules, driver interfaces etc.,
         6. Networking stacks, Filesystem internals, SMP, 
virtualization...and other advanced topics.

     c. I personally would be fine with pre-meeting prep, but if the 
group decides to go with homework or both, its fine by me.

     d. Typical kernel source code archives are


Andrew Wilcox
I have an old book that describes the Linux 2.2 kernel, "Linux Core
Kernel Commentary".  Maybe someone could write an update to 2.6 for
it.  It would seem like an interesting project (I personally don't
have the time for it right now, however).  It's a fantastic book -- it
covers some of the "stranger" parts of the kernel (i.e. SMP,
scheduling) in more understandable terms than just the source code.
It also contains a full print out of the whole core of the kernel
code, cross-referenced with the commentary.

Here's a link to the book on Amazon: 
Also, there seems to be a 2nd edition for the 2.4 kernel at
http://www.amazon.com/gp/product/1588801497 -- I do not personally
have this edition, but it may be worth looking in to.

and in another post Andrew wrote:
Not sure if we might want to discuss the multiboot record or not?
Fairly trivial, but probably worth mentioning.
(this was in response to Bruce Coston)


Akkana Peck
I don't mind pre-session assignments like that. But depending on the
module we're reading, it might help to have someone give some
background in what the module does if it's not obvious, so we're
not just blindly reading lines of code and trying to guess.

It would be really cool to have homework like "Now try tweaking this
code to do foo" and see what people come up with and what problems
they have.

That would be excellent if people wanted to cover different types of
modules.  Some might be more interested in scheduler details, some
in network algorithms, some in USB drivers. But that'll become
clearer after several sessions -- we're probably fine with one group

and in another post Akkana wrote:
Several people have expressed interest in startup and init.
I'm not sure if there's a lot of interesting actual kernel code
involved there, but if there is, I'd be interested too.

How the process table is managed might be another good place
to start (and we'd get a better understanding of things like
those pesky zombie processes).

Specific kernel areas I'd love to learn about:

- ACPI and power management, how suspend (to RAM or disk, but
   especially RAM) and ACPI sleep states are managed, and what
   happens on resume. And what's up with those unkillable daemons
   running in kernel space?

- Udev.

- The "completely fair scheduler" and how it can help desktop
   processes (and it would be interesting to hear ways that the CK
   scheduler might have differed, if anyone knows).

- A USB driver or two -- device drivers are one of the areas where
   it might be most possible to contribute, and so many devices are USB.
   (Maybe choose some USB class where a lot of devices still don't
   have drivers, like webcams.)

- The new wireless infrastructure, and analyze any specific wireless
   driver -- as with USB drivers, it's an area that needs help, so if
   we can learn how the system works, we might be able to contribute.


Larry Colen
I suspect that just doing
anything along these lines will have the very significant effect of
giving other people the idea of holding these code walkthroughs.

I would like to suggest that at each meeting we ask someone to
volunteer to note down any potential bugs, or documentation errors.
Code walkthroughs are helpful for more than just people learning the


and in another post Larry wrote:
I find that having context really helps me learn things like this, so
I think that a good place to start would be a high level overview. The
general structure of the kernel.

Online supplements would be URLs of good places to look for info, and
maybe some faqs for etiquette on the lkml etc.

For digging into the code, I'd probably want to start with a fairly
high level look at what happens when init() is called.


bruce coston
Beginning should be easy, Boot - probably with GRUB as its the most 
common method now. Or start just after that as GRUB is not the kernel 


Philip Martin
I think there's some interesting stuff there.  All the PCI bus
initialization, which would provide a nice segue into device driver
loading and ACPI.  The whole init process (as in /sbin/init) is
outside the kernel, but would be a great place to start looking at the
linux process lifecycle, process table and scheduler.

Maybe we should group things into umbrella concepts which can be
covered in a number of sessions.  Each session should be as atomic as
possible, however, to enhance retention.  Something like:

major kernel data structures (atomic_t, kernel_size_t, etc),
conventions (locking), utility functions, etc.

booting and device discovery (ACPI, bus initialization, device
discovery, device driver loading, udev)

process management (process lifecycle, process table, process scheduler, 

device drivers (general framework, specific types, etc)

VFS (VFS layer, IO scheduler, ext2, ext3, etc)



The progression should be logical and should hopefully build upon what
has come before.


Brian J. Tarricone
is there a need to standardise on a
particular version that everyone will follow?  Presumably 2.6 will be
covered, but, for example, 2.6.12 is very different from 2.6.23, since
active development is occurring on the 2.6 series.  Things like the
recent addition of a new CPU task scheduler, a new default memory
allocator, and even many of the VM changes occurring early in the 2.6
series might make for some confusion if people are on different versions.

More information about the svlug mailing list