When planning a kernel development project, it makes great sense to hold discussions with the community before launching into implementation. Early communication can save time and trouble in a number of ways:
- It may well be that the problem is addressed by the kernel in ways which you have not understood. The Linux kernel is large and has a number of features and capabilities which are not immediately obvious. Not all kernel capabilities are documented as well as one might like, and it is easy to miss things. Your author has seen the posting of a complete driver which duplicated an existing driver that the new author had been unaware of. Code which reinvents existing wheels is not only wasteful; it will also not be accepted into the mainline kernel.
- There may be elements of the proposed solution which will not be acceptable for mainline merging. It is better to find out about problems like this before writing the code.
- It’s entirely possible that other developers have thought about the problem; they may have ideas for a better solution, and may be willing to help in the creation of that solution.
Years of experience with the kernel development community have taught a clear lesson: kernel code which is designed and developed behind closed doors invariably has problems which are only revealed when the code is released into the community. Sometimes these problems are severe, requiring months or years of effort before the code can be brought up to the kernel community’s standards. Some examples include:
- The Devicescape network stack was designed and implemented for single-processor systems. It could not be merged into the mainline until it was made suitable for multiprocessor systems. Retrofitting locking and such into code is a difficult task; as a result, the merging of this code (now called mac80211) was delayed for over a year.
- The Reiser4 filesystem included a number of capabilities which, in the core kernel developers‘ opinion, should have been implemented in the virtual filesystem layer instead. It also included features which could not easily be implemented without exposing the system to user-caused deadlocks. The late revelation of these problems – and refusal to address some of them – has caused Reiser4 to stay out of the mainline kernel.
- The AppArmor security module made use of internal virtual filesystem data structures in ways which were considered to be unsafe and unreliable. This code has since been significantly reworked, but remains outside of the mainline.
In each of these cases, a great deal of pain and extra work could have been avoided with some early discussion with the kernel developers.