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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 31 Mar 2011 23:40:11 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Nicolas Pitre <nico@...xnic.net>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	david@...g.hm, Ingo Molnar <mingo@...e.hu>,
	Arnd Bergmann <arnd@...db.de>,
	Tony Lindgren <tony@...mide.com>,
	David Brown <davidb@...eaurora.org>,
	lkml <linux-kernel@...r.kernel.org>,
	linux-arm-kernel@...ts.infradead.org, linux-omap@...r.kernel.org,
	Catalin Marinas <catalin.marinas@....com>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [GIT PULL] omap changes for v2.6.39 merge window

On Thu, 31 Mar 2011, Nicolas Pitre wrote:
> 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 

The main help we can give (aside of actually looking at code and
concepts) is to feed back the experience we have with massive cleanups
and which mechanisms work and which not and - at least I can speak for
myself - to stand at your side when it comes to pushing that through.

One thing what really helps to force people to get their act together
is that you as maintainers identify trouble spots which are easily
addressable. Then put those spots on your list and require people who
want to submit new features in that area to cleanup the mess first and
then put their new feature thing on top. We successfully used this to
get the unification work after the mechanical i386/x86_64 merger
done. It requires a lot of stubborness, but it reduces the work burden
of the maintainers a lot.

Once you have the easy spots addressed, that could be device tree
stuff, gpio, irq_chips for the beginning and see how it works out,
then go steps further.

The important point here is from my POV that you put down the
requirements with no wiggle room and just ignore the "oh it could be
done better" whining. Either people come up with a patch which solves
the whole issue better or they just will cope. But when you have
consolidated stuff then you can and need to look from a high level
perspective and refine the infrastructure.

I really regret in hindsight, that I did not enforce the cleanup of
the irq layer way earlier and that I did not see the abuse of it early
enough. At some point I realized that being polite is the wrong
solution, so I forced myself to push this cleanup through. That's an
experience which I don't wish anybody else to make. Especially because
as long as the oldstyle stuff works oldstyle crap comes in faster than
you can fix it. See commit 9ad198c. And it's a massive effort to do
something which results in:

Total patches:                 414
Total files touched:	       702	
Total insertions:             6805
Total deletions:              8632
Lines added                  -1827

And that massive effort is just because you cannot break stuff after
the fact in a massive scale. The whole thing introduced a mere 6
patches fixup fallout which were applied one day after rc1. It could
have been avoided, but ....

So yes, we can and will help with advise, a certain amount of review
(especially on the concept level) and giving you all the support you
need to fight that trough.

Thanks,

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