Greg Kroah-Hartman: Android and the Linux kernel community

Posted Feb 3, 2010 19:30 UTC (Wed) by dlang (guest, #313)
In reply to: Greg Kroah-Hartman: Android and the Linux kernel community by dlang
Parent article: Greg Kroah-Hartman: Android and the Linux kernel community

actually, I need to clarify my last statement.

temporary forks are definantly common in linux development. The key is that they are temporary with the intent being to merge them as the ideas that caused them to be created are tested.

Every developer who submits patches to linux is technically doing this, but there is a long track record of larger forks. The RT tree is a perfect example of this, they forked and did a lot of work, and are now getting that work merged back in.

so forking is bad, but fork + merge is the bread and butter of kernel development

Greg Kroah-Hartman: Android and the Linux kernel community

Posted Feb 4, 2010 14:44 UTC (Thu) by nevets (subscriber, #11875) [Link]

I am one of the RT developers and even maintained the RT tree for a while in the past.

When we first started working on -rt, it was not too different from Android. That is, we were working in a niche market. We did not even know that mainline needed anything we were doing. At the time it was more R&D.

Maintaining a tree outside of mainline is extremely difficult. As -rt developed, we realized that it has advantages for mainline. But more importantly for us, the more we got into mainline the easier our job would be.

Mainline was a mess with respect to Real-Time. We started sending in patches to clean it up. We started combining more spin_lock() and local_irq_disable() into spin_lock_irq() which helped mainline annotate what locks were being used in interrupt context and which were not.

hrtimers, generic timers, generic interrupts, lockdep, ftrace, mutex, pi futex, and a list of others all came from this -rt work.

Once we realized that -rt was worth the effort, we started working hard to get all of it into mainline. If we just passed the patch over to the mainline developers and said, here it is, take it or leave it, they would have laughed in our faces. Ever single enhancement that we had in -rt, we had to rewrite 2 or 3 times before it was acceptable for mainline.

Having your code in mainline will make things much easier in the long run. Believe me, it can be hell to constantly keep up with mainline. If you look at your work and ask yourself, how could this help everyone not just our little niche, you will see better solutions that will not only help mainline, but will also help you. Every time we did a rewrite, the end result was always something better for the RT tree.

Listen to the mainline developers, they may actually make your product better.