Re: [GIT PULL] omap changes for v2.6.39 merge window

[Nicolas Pitre]

On Thu, 31 Mar 2011, Linus Torvalds wrote:

> What I'm _not_ seeing is a lot of cross-platform maintenance or sense
> of people trying to reign things in and look for solutions to the
> proliferation of random stupid and mindless platform code.

I do that, Russell does that, Catalin does that, Tony does that, and 
maybe less than a handful of other important people I'm not listing 
(sorry).  But clearly we are far far from being enough people doing that 
kind of work.  And the fact is that the volume of ARM platform code is 
steadily being produced at a rate far surpassing X86, and even higher 
than all the other architectures put together.  Linaro is trying to help 
here, but Linaro cannot conjure the needed experience and knowledge for 
that kind of work with a magic wand.

So we need help!  If core kernel people could get off their X86 stool 
and get down in the ARM mud to help sort out this mess that would be 
really nice (thanks tglx).  Until then all that the few of us can do is 
to contain the flood and hope for the best, and so far things being as 
they are have still worked surprisingly well in practice for users.  If 
compensation is a concern then I think Linaro might be able to arrange 
something.

And we can't count on vendor people doing this work.  They are all busy 
porting the kernel to their next SOC version so they can win the next 
big Android hardware design, and doing so with our kernel quality 
standards is already quite a struggle for them.

What is going on at the moment is some effort to introduce DT support to 
ARM.  The core support is there, but that is useless until platform code 
is moved to it, and corresponding work is put into bootloaders, etc.  
That is progressing... slowly.

Also there is some work to be able to build a kernel supporting more 
than one SOC family at once.  Of course there is no practical use for a 
single kernel binary that boots on all existing boards, but moving 
towards such a goal has beneficial side effects such as good 
consolidation when possible.

But we also need some slack wrt number of lines changed.  An increased 
consolidation effort will create more churn not less, at least for a 
while.  The OMAP clock merge conflict was the result of some cleanup 
which will make further consolidation easier.


Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/