Merge window and Linux-Tiny work

The merge window for the 2.6.28 kernel has been opened about two weeks ago and has now be closed with the release of 2.6.28-rc1. In the context of my work at Free-Electrons, I have the opportunity to contribute to the Linux-Tiny project, whose goal is to try to reduce the size of the kernel. Some of my patches have been integrated during this merge window :

• PCI quirks disabling patch, which allows to remove almost 12 Kb of kernel code/data
• AIO disabling patch, which allows to remove ~7 Kb of kernel code/data when asynchronous input/output operations are not needed
• file locking disabling patch, which allows to remove ~11 Kb of kernel code/data when file locking is not needed
• x86 CPU architecture selection, which allows to remove ~6 Kb of kernel code/data by disabling code only used for other CPU types. This modification in fact involved several distinct patches.

It's amazing to see how the kernel workflow works well. I haven't had to care about sending these patches during the merge window: I just submitted them to the proper subsystems maintainers, and they took care of updating them as needed and sending them to Linus once the merge window opened. Once one change has been accepted by a subsystem maintainer, the Linux kernel contributor doesn't have to do anything to see his patch integrated in mainline. This is how dozens of thousands of patches are merged between every kernel version.

However, the Linux-Tiny patches specifically are not always well received by the kernel community. Most of them are patches that add new configuration options to disable features. But most of these features are seen as absolutely mandatory for non-embedded developers, even though a kernel can work perfectly fine without them in certain conditions, conditions which can be guaranteed to be true on embedded systems were the environment, feature-set and used applications are most of the time precisely defined. Developers also tend to not like them because more configuration options means more #ifdef machinery and more complexity for future maintenance, which is an absolutely valid concern. But numbers clearly show that the size of the kernel is growing over time, and this is problematic to embedded users who care about size.

See also my report of Matt Mackall's talk at Embedded Linux Conference this year concerning kernel size, and the associated video.