The Kernel Newbies Crash Course LKD4 Challenge! Play along at home!

[Robert P. J. Day]

  In the spirit of the Eudyptula Challenge, we here at the Crash
Course Linux Training Centre and Craft Gin Appreciation Institute
introduce the LKD4 Challenge. Everyone can play ... fun for the whole
family, ages 6 and up.

  Seriously, though, if you're looking for something to put your Linux
kernel understanding to work with a challenge you probably can't get
kicked out of, here's a suggestion.

  It's sort of explained here:

http://www.crashcourse.ca/wiki/index.php/Updates_to_LKD3

although it's been a while since I've added anything to that page so I
probably need to do a bit of updating and restructuring, but here's
the short version.

  There are frequent references on this list to the standard books
that any kernel newbie should have (along with their common acronyms
for brevity):

 * LKD3: Linux Kernel Development (3rd ed), by Robert Love
 * LDD3: Linux Device Drivers (3rd ed), by Corbet et al
 * ELDD: Essential Linux Device Drivers, by Venkateswaran

Sad part is that at least the first two of those books are starting to
show their age -- I should know about LKD3, I was the technical
editor. Yes, you can look inside at the masthead and that's me.

  Now, there is absolutely *no* schedule for an LKD4 (yet), but it
doesn't hurt to look ahead and prepare for it if it happens. It's
possible I might tech edit that next edition but, even if not, it
doesen't hurt to prepare for it, which is why I started that wiki
page; to start keeping track of everything that would need to be
updated.

  If you want to play along, the rules are pretty simple (actually,
the rules are non-existent, you just have to want to participate).
First, you need a copy of LKD3. And, second, you just need to figure
out what needs updating. That's about it.

  This doesn't require a massive investment of time -- you don't need
to tackle entire sections or chapters at once. An update could
represent something as simple as a change to a single line or single
paragraph, an update to a filename, a revision to a listed snippet of
code or what have you.

  You also don't need to try to deal with the whole book -- just pick
the part of the Linux kernel that most interests you and work on that.
As for what constitutes reporting an "update", it's pretty flexible
but it's always best if you try to be complete and provide as much
context as possible.

  As a hypothetical example, say a listed structure in LKD3 has
changed since publication -- then that's something that should be
reported as an update. But don't stop there. Figure out *why* it
changed, perhaps identify the Git commit where it happened,
investigate what else might have been affected by the same commit, and
so on.

  Other things to be reported would naturally include:

  * new features added since publication
  * entire subsystems deleted since publication
  * suggestions for topics that should be covered in more detail

It's all very open-ended -- just a totally *unofficial* project to
update LKD3.

  Finally, while that's a wiki page, I'm reluctant to make it
world-writable given the immediate infestation of spammers, so people
are free to just email me, and I can add their stuff and give them
credit if they want. It's all in good fun and, in the end, the goal is
to improve the content.

  Questions?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================