On Thu, Mar 31 2011, Nicolas Pitre wrote: > Leaf nodes on ARM are people coming from corporate background with the > old school software development methodologies. They do it as a _job_ > first and foremost. They only work on Linux because that's what their > boss assigned them to. Don't get me wrong: that doesn't mean they are > bad people. Simply that they are not into it for the public recognition > (or flaming) from their peers. Once their code works they lose interest > and move on. That mindset is extremely hard to change and take time, on > a scale of years. Much more time than required to produce the code > needed to support that new SOC out of the pipeline. There are notable > exceptions obviously. But this is still a scalability problem in > itself. So we need men-in-the-middle attacks. An additional mindset that is difficult to work with in this environment is that the corporate development methodology has a focus on schedules and deliverables. Even people who would otherwise like to contribute will have pressure to get something done. Many think of "submit to mainline" is kind of a last step in a development process, instead of even a goal to accomplish. When we push back, there is a good chance they just won't bother, not because they don't want to do it, but because it doesn't fit a schedule, and there is already something else for them to work on. So what's the right answer here. Practically, someone just sent out a fairly complete DMA driver for a new MSM device. Naturally, this hardware is nothing like anyone else's DMA, but the driver itself pretty much independent from other kernel APIs. It isn't even similar to the existing DMA driver in the MSM. With it are patches to ifdef-up various drivers to use the appropriate DMA. The DMA code, by itself, seems reasonably well written (with some cleanup and such needed), but it makes everything that uses it messy. In this particular case, DMA engine will probably need some work to either incorporate the unique capabilities of this hardware, or at least allow them to be used. The author probably won't be able to do this on their own. I could pull the driver into the tree, and now we have yet another driver with yet another API. If I push back, realistically, it will probably end up out-of-tree, along with everything that depends on it. Up until now, it seems that attitude has been that it is better to be in-tree than out of tree, but are we getting too much stuff to continue that? Today, most of the MSM code lives out of tree. The QuIC tree for MSM (currently based off of 2.6.35): git diff --stat v2.6.35..HEAD | tail -1 3432 files changed, 1144473 insertions(+), 17315 deletions(-) git diff --stat v2.6.35..HEAD arch/arm/mach-msm | tail -1 595 files changed, 286054 insertions(+), 1928 deletions(-) There's a large amount of work just to get the code up to kernel standards (the coding style has been fairly well enforced), and there is constant development for new hardware. Thanks, David Brown -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
