while i'm assigning dev kits to people based on my earlier project, i have another venture i'm not sure what to do with so i'll just explain it and let people make suggestions. this requires no extra hardware and has no immediate compensation based on what you do except the chance to learn a lot more about linux kernel programming. you'll see what i mean. (and, yes, i'm going to be verbose again but i need to make it clear what i'm after.) at the moment, i'm involved in a massive rewrite/update of not just my own kernel/embedded/device driver courseware but some other content as well. my idea is that, for all of the kernel features i want to document and discuss in my updated courses, i want really minimal examples that, as much as possible, demonstrate a *single* feature of kernel functionality. and surprisingly, examples like that are not that easy to find. most folks are familiar with the book "linux device drivers (3rd edition)" [aka "LDD3"], which is now available online for free here: http://lwn.net/Kernel/LDD3/ in its day, it was a spectacular book, but it is definitely showing its age so any examples i want to scarf from that book would probably need updating. but that's not all. one of the common(?) complaints about that book is that it launches into a working example of writing a character driver with a first example that is simply too complicated, to the point where the fundamentals of character drivers are lost in the maze of following along with the memory allocation and linked lists and so on. as an alternative (and at the risk of sounding self-serving but i'm not as you'll see shortly), that's why i wrote this online intro to kernel programming once upon a time: http://crashcourse.ca/introduction-linux-kernel-programming/introduction-linux-kernel-programming yes, i know it costs $39 for the whole course but a) the first several sections are totally free and b) don't buy it. seriously, don't buy it, it needs updating and i'm grappling with eventually putting a slightly stripped and updated version up for free, anyway. but the first few lessons are now the basis for how i start teaching how to write, compile and load the simplest possible loadable module and, little by little, work my way up to a trivial character driver, then launch into device drivers in general. so my goal is two-fold: a) updated content, applicable for the current kernel source tree, b) really *tight* examples that explain a single concept with no extraneous fluff to get in the way of the explanation so, basically, i'm throwing out the offer for people who want to goof around and write really simple examples of kernel modules that test and demonstrate whatever specific feature interests them, then letting me just walk off with said examples for my updated courseware. but wait, there's more. first, it's not hard to find examples like that out there on the net. a number of people have already started projects to bring the code from LDD3 up to date, like this: https://github.com/jesstess/ldd3-examples which is nice but, as i mentioned, some of the stuff from LDD3 is just too complicated and i'm still looking for shorter, more focused examples, particularly for introductory material. i've also run across examples like this: http://people.ee.ethz.ch/~arkeller/linux/kernel_user_space_howto.html but while some of the examples there are more suitable, even some of those need updating (the ioctl example doesn't work since the "ioctl" member field has been replaced with two newer versions). and some of those examples are, again, crazy long so i'd want more minimal versions. unsurprisingly, to try to cover all of basic kernel programming and introductory device drivers with simple examples is a monstrous undertaking, which is why i'm crowdsourcing it for people who want to play along. the other thing that goes along with this is to crowdsource watching for new features that are worth mentioning in any decent course. for instance, i totally missed this thing called the Contiguous Memory Allocator: http://lwn.net/Articles/468044/ and even though it's not in mainline yet(?), it's worth watching. so people who wanted to get involved could also keep an eye out for stuff like that so i can keep a list, even if it doesn't make it into the material yet. and beyond the basic stuff, i'm always on the lookout for ways i can *simulate* kernel features for classroom demonstration. for example, WRT udev, there's "udevadm test" which does a simulation run of udev processing. i'm always *hugely* interested in anything that lets one "test" kernel features via emulation or simulation. so, how to do all this? obviously, it would make sense to create a new forum for people who want to play along, and it's easy enough for me to create a new mailing list at my crashcourse.ca site, and some (restricted) wiki pages to keep track of all this. i realize it sounds like i'm asking people to do all of this for me for free. well, actually, i guess that *is* what i'm asking. :-) but in exchange, i can help folks if they need assistance, and anyone who wants to participate can also see the results of *others'* work. to keep things manageable, i don't want to just throw this open to all and sundry. it would be nice to have a small (maybe 6-8) group of participants who are interested, who will have acccess to the mailing list and to all of the web pages as these things are documented. as stuff is written, i'll definitely post *some* of what's written, but not so much that it diminishes the value of the eventual courseware. i'll figure something out there -- obviously, there's a balance to be found here. so, does any of this make sense? as i mentioned, this is something that doesn't require any actual investment in hardware or software, just time and an interest to poke around in kernel internals and write little programs to show how things work. thoughts? rday p.s. for people who will be working with those dev kits, all of the above extends to writing simple programs that demonstrate features that are relevant *only* on non-x86 architectures. for instance, on things like pandaboards, there are simple recipes for how to, say, turn on one of the LEDs by writing to the appropriate /sys directory entry. but that sort of thing is architecture-dependent. again, thoughts? i already know this is a spectacularly ambitious plan. hence, my appeal for assistance.