On Thu, Mar 31, 2011 at 12:25 PM, Nicolas Pitre <nico@xxxxxxxxxxx> wrote:
>
> 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.
The thing is, maintainers don't scale.
The only way to get quality code is to try to improve the quality from
the "leaf nodes", because otherwise you'll always end up playing
catch-up. You'll get new bad code faster than you can clean it up.
I've told people this before, and I'll tell it again: when I flame
submaintainers, they should try to push the pain down. I'm not really
asking those submaintainers to clean up all the stuff they are
getting: I'm basically asking people to say "no", or at least push
back a lot, and argue with the people who send you code. Tell them
what you don't like about the code, and tell them that you can't take
it any more.
> 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.
This really isn't the argument. The argument should be that if they
want their code up-stream, they need to do a good job. If they don't,
why should you take it at all?
> 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.
How about not moving platform code TO it, but at least saying that you
won't accept new platform code that doesn't use it? When somebody
sends you a new platform, just say "no" if it's another copy-paste job
or another "add yet another #ifdef or conditional to a messy driver".
> 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.
Umm. The whole "number of lines of code" thing has become a total red herring.
THAT IS NOT WHY I STARTED TO COMPLAIN!
The reason I point out the number of lines of code is because it's one
of the more obvious _symptoms_ of the problem.
But trust me, if you start doing a better job at platform code, I
won't be complaining when I get lots of deleted code, or when I start
getting devicetree descriptions instead of new drivers.
So "number of lines of code" and "massive churn" is a problem, but
look at how I'm not complaining about the drivers/ subdirectory, which
is still the bulk of all lines in the kernel by far. I may complain
about particular subsystems in drivers (gpu..) for other reasons, but
it's not "lines of code" per se.
In the case of ARM, the reason I point out the size of the arch/arm is
because it's illustrative of just how _different_ ARM is from the
other architectures. And those differences are pretty much all about
the board/platform issues.
Linus
--
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
