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:	Fri, 18 Mar 2011 00:06:55 -0700
From:	Tony Lindgren <tony@...mide.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Russell King <rmk@....linux.org.uk>,
	David Brown <davidb@...eaurora.org>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-omap@...r.kernel.org
Subject: Re: [GIT PULL] omap changes for v2.6.39 merge window

* Linus Torvalds <torvalds@...ux-foundation.org> [110317 19:48]:
> On Thu, Mar 17, 2011 at 11:30 AM, Tony Lindgren <tony@...mide.com> wrote:
> >
> > Please pull omap changes for this merge window from:
> 
> Gaah. Guys, this whole ARM thing is a f*cking pain in the ass.
> 
> You need to stop stepping on each others toes. There is no way that
> your changes to those crazy clock-data files should constantly result
> in those annoying conflicts, just because different people in
> different ARM trees do some masturbatory renaming of some random
> device. Seriously.
> 
> That usb_musb_init() thing in arch/arm/mach-omap2/usb-musb.c also
> seems to be totally insane. I wonder what kind of insanity I'm missing
> just because I don't happen to see the merge conflicts, just because
> people were lucky enough to happen to not touch the same file within a
> few lines.

This merge conflict was really unfortunate, the plan was to queue
driver related changes via the usb-devel list and the platform init
changes via the linux-omap list. But obviously something went wrong..

Anyways, we are close to done making the platform init code shared
between omaps and then drivers become arch independent. So things
should get easier for next merge window already.
 
> Somebody needs to get a grip in the ARM community. I do want to do
> these merges, just to see how screwed up things are, but guys, this is
> just ridiculous. The pure amount of crazy churn is annoying in itself,
> but when I then get these "independent" pull requests from four
> different people, and they touch the same files, that indicates that
> something is wrong.

Well in this case the conflicts were between driver changes and arch
related changes :) For the ARM and various ARM related SoC changes
there is a lot of work going on to make things more generic. So with
that the crazy churn should also ease, but it takes a lot of work to
get there.
 
> And stop the crazy renaming already! Just leave it off. Don't rename
> boards and drivers "just because", at least not when there clearly are
> clashes. There's no point. I'm not even talking about the file renames
> (which happened and can also make it "fun" to try to resolve the
> conflicts when somebody else then makes _other_ changes), but about
> the stupid "change human-readable names in board files just to annoy
> whoever needs to merge the crap".

OK, point taken. One part of the problem here are the current dependencies
between the driver code and platform code which makes it hard to patch
one without the other. Hopefully this will too ease as the drivers
become separated from the platform code.
 
> Somebody in the ARM community really needs to step up and tell people
> to stop dicking around.
>
> (I'm replying to the omap pull request, because that's the one I did
> last, but I don't know who to "blame". I don't care. It really doesn't
> matter. I realize thar ARM vendors do crazy shit and haven't figured
> out this whole "platform" thing yet, but you guys need to push back on
> the people sending you crap).

OK we'll pass on the message.

Regards,

Tony
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ