Batman-adv and the Penguin join forces
The Linux kernel 2.6.38 (released 2 days ago) is the first Linux version officially shipping the batman-adv kernel module. Although the code already entered Linux space in 2009 as part of the Linux staging tree (place for preparing kernel modules to be officially accepted). In late June 2010 Greg Kroah-Hartman, our tree maintainer, gave us his blessing to leave the Linux kernel staging tree and move to a more suitable location. It took several sessions of code review and changes with David Miller before he made us an early Christmas gift by merging the batman-adv module into the Linux kernel net tree. Since then an often asked question is: What did it take to make the kernel module "acceptable" by the Linux kernel hackers and which parts of the code did you have to change in the process?
Of course, being Linux kernel coding style compliant and the code refactoring that comes with it definitely was one of the larger chunks on the way into the Linux kernel land. There always has been a lot of discussion about whether or not the Linux kernel coding style rules are (partially) old fashioned, too strict or a burden but consider this: Even hundreds of contributors for each release manage to work on the same code base to produce a coherent piece of code that is relatively easy to navigate, once you understood the coding style, taking into account its enormous size. To achieve the "Linux kernel natural" feeling we also had to adjust the administrative handling of the project, like making small and digestible patches which have to go through our mailing list while enforcing the Linux kernel patch submit "regime". At some point every patch will be forwarded to our tree maintainer who may reject the patch if it did not meet the style requirements. Having the same requirements in place helps avoiding rejected patches. Our release process underwent major changes too: The different branches now contain patches for the current stable release / the upcoming Linux kernel respectively. The 3 months release cycles & feature freezes have become a regular event, the heartbeat of the project.
The technical aspect required much attention too: Each citizen of the wide Linux kernel land is expected to re-use existing infrastructure and to avoid code duplication at all costs. This includes employing kernel constants instead of hard-coded numbers or own definitions (e.g. ETH_ALEN, NET_RX_SUCCESS, NETDEV_TX_OK, ..), kernel provided functions instead of manually written counterparts (e.g. hweight_long(), compare_mcast_addr(), min() macro, msecs_to_jiffies(), ..) or even integrating whole "libraries" like the list implementation, reference counting or rcu locking. Next to the obvious advantage of reducing the binary size it bears the appealing characteristic that this code is better debugged and optimized as it is shared among a large group of developers and users. Absolutely forbidden are Linux kernel version checks in the code base, something that was found everywhere in our code to cope with API changes because we wanted our module to also be compatible with older Linux kernel versions. The solution was to concentrate all incompatibility workarounds in a single file (compat.h) which is only part of the external release tarballs. Another no-go was the in-kernel support for specific output formats our mesh graph visualization offered. This formatting can easily be handled in user space. As a result the batman-adv kernel module now outputs a single neutral format. The batctl user space tool showcases how to convert this output into other formats. The initial and somewhat simple procfs configuration and debug interface had to be migrated to sysfs (the settings) and all debugging related functionality moved to debugfs. Since we reside in the official Linux kernel source tree our code has been analyzed by static analyzers (Coccinelle/sparse), we received patches for API changes on multiple occasions and insightful code review feedback.
We are very excited about the results. This was quite an experience which helped to improve the overall code quality while helping us to understand the Linux kernel better. However, this is just the beginning. Many more patches and features are already in preparation and will shape future releases.
The B.A.T.M.A.N. team