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 ======================================================================== _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
