[pabb]

I know you meant well, but to give such a stern warning and then admit that you haven't done any kernel-related work at all is frustrating. I've just been getting involved in kernel development for the past month, and it's pretty clear that the go-to taskss for novices is primarily writing device drivers or fixing bugs. I'm not sure what fraction of kernel developers get to work on the kernel core (CPU scheduling, boot/initialization, file systems, memory management), but I'm going to guess it's relatively small, or at least isolated compared to those working on drivers and other modules.

Further, if the maintainers were so cautious as to want to limit contributions to the kernel, you wouldn't see initiatives like the aforementioned (and awesome) Eudyptula Challenge, or Greg KH's "Linux Kernel In a Nutshell", which he chose to give away for free in order to garner more interest in kernel dev. The state of the project right now is clearly weighted towards getting new involvement as opposed to discouraging contribution because of extremely rare and unlikely cases like the one you mentioned.

[thegeomaster]

I don't think you have to do kernel work to warn people they should be cautious when submitting to mainline. As a matter of fact, I've read the book you mentioned, alongside some others such as Understanding the Linux Kernel by Bovet and Cesati, and I've brushed against low-level kernel features such as memory-mapped I/O or epoll, so I'm at least aware of what might go wrong if you decide to write a kernel module just for fun and then issue a pull request against the original source tree.

I don't think contribution should to be discouraged, but I do think that people who have no sense of responsibility should be kept away from the kernel source. Kernel development is not supposed to be for everyone, it's hard. Great expertise and technical mastery is needed to write good, quality and responsible code that is suitable for inclusion into a kernel that today powers so many different devices.

I will admit, again, that my warning was probably too harsh, but I still stand firmly by the viewpoint that "casual" or careless kernel contribution should be a no-no. It's one thing to poke around on your dev system to find out how stuff works, but entirely another to write an official patch to a system that millions of people around the world rely on.

EDIT: And when I say that "kernel development is hard", I mean that it's harder in the general case than writing most userspace code. It requires you to think of stuff you don't usually worry about (think of the all the race conditions that might occur) and let go of all the abstractions provided to you by the kernel, it's harder to debug than userspace programs, and you have to support a wide variety of hardware platforms, each with its own quirks. In fact, I haven't done any kernel development just because I was intimidated by how hard it is. I've tried writing a kernel from scratch (OSDev wiki was a great help) but it soon came to be a buggy and unmaintainable set of kludges that was barely doing any real work.

EDIT #2: Why I can't reply to replies to this comment? Is there a conversation depth limit on HN?

[akerl_]

"Kernel development is not supposed to be for everyone, it's hard."

Citation?

Given you've admitted to not working on kernel code, this seems like something you've determined out of reverence for the importance of the kernel, not something grounded in fact.

It's worth noting that the entire Linux project spawned from some "casual" development work by somebody doing it as a hobbyist project.

[adrianm]

Your last point is just, ugh, oh so true. You don't get to be an expert in any field without diving head first into them at some point as an inquisitive amateur. Having a curious, naive spirit who isn't afraid to do things "the wrong way" and break a few things along the way is something we should be encouraging in our fellow hackers!

The OP's misaligned sense of responsibility honestly terrifies the child in me. I would not be where I am today were it not for the countless circuit boards I went through (nice way of saying completely destroyed) when I was 12.

[aquayellow]

True. If you follow LKML, you will notice that the majority of changes are to the device drivers code. And it makes sense, after all, you want the kernel to run on a wide variety of hardware. So, it's not just what fraction of developers work on the core but rather, what the fraction of changes belong to the core kernel - which is relatively small compared to the device drivers code.

Another good way of getting into kernel hacking is not just device driver books but following mailing lists you are interested in. netdev, pci-devel, kvm are some of the interesting ones. Also, checkout GregKH's driver project - these are drivers that are not yet fit of inclusion and hence reside in a "staging" area - a great way to get involved in kernel development ( http://linuxdriverproject.org/mediawiki/index.php/Main_Page). Note that some of the lists can have really high traffic but eventually you will get the hang of picking out the useful stuff. https://lwn.net/Kernel/Patches is a great resource for mention-worthy kernel patches without subscribing to individual lists.

I also agree with you that maintainers will _not_ be cautious and prevent newcomers. That's a bunch of bull. If at all, maintainers will be welcoming to changes from first timers and will thank you for your contributions if your changes do get in. Maintainers or other developers usually are frustrated with other style issues though - for example, lines greater than 80 chars, using a mail client that mangles your patch and so on. But keep in mind that the frustration is on the patch you posted, definitely not on you on a personal level :)