linux-kernel - Re: linux-next: manual merge of the arm-soc tree with the arm tree

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] [day] [month] [year] [list]

Date:	Fri, 25 Nov 2011 17:08:27 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Shawn Guo <shawn.guo@...aro.org>,
	Magnus Damm <magnus.damm@...il.com>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Russell King <rmk@....linux.org.uk>,
	Paul Mundt <lethal@...ux-sh.org>
Subject: Re: linux-next: manual merge of the arm-soc tree with the arm tree

On Thursday 24 November 2011, Shawn Guo wrote:
> On 24 November 2011 23:54, Arnd Bergmann <arnd@...db.de> wrote:
> > On Thursday 24 November 2011, Stephen Rothwell wrote:
> >> Hi Arnd,
> >>
> >> Today's linux-next merge of the arm-soc tree got a conflict in
> >> arch/arm/tools/mach-types between commit bb9b25f923fc ("ARM: Update
> >> mach-types") from the arm tree and commit 9b7c547f7747 ("ARM: Update
> >> mach-types to fix mxs build breakage") from the arm-soc tree.
> >>
> >> The arm tree version is a superset of the arm-soc version, so I used that.
> >
> > Thanks for catching this!
> >
> > Shawn, please make sure that any updates to mach-types go only through
> > Russell's tree. Unfortunately I did not realize that this was out of
> > scope when I merged it, otherwise I would have complained yesterday.
> >
> Sorry if I have misunderstood Russell's comment below.
> 
> http://thread.gmane.org/gmane.linux.ports.arm.kernel/139196/focus=140505
> 
> But I thought he would not send patch on mach-types for -rc series.
> That's why I came up with this patch and sent it to you.  After all,
> we do not want to see mxs build breakage in a release.

What Russell said was that he would not send a full update of
the mach-types file during -rc, because that would remove lots
of (broken) entries and consequently cause build regressions.

He did already send a patch 628e1110 "ARM: Add a few machine types
to mach-types" with a manual update, and normally I'd say your patch
should go the same way.

We also still need to sort out the underlying problem that Russell
mentioned in the thread, which is that he doesn't want to add any 
entries that are not used, while I don't want to add any code that
doesn't build (which a machine definition doesn't without the
mach-types entry).

The best solution I can think of is if I ask people to manually
add a line for their machines when a new one gets added (this
should be getting rarer in the future) and I check that the
line is identical to the one that we get after Russell does the
next update. The main disadvantage with this approach is that
it generates a lot of trivial merge conflicts that the database
was originally meant to avoid.

I also noticed that there is a second missing entry for a board
that Paul Mundt added recently:

$ git grep ^MACHINE_START arch/arm/ | cut -f 2 -d \( | cut -f 1 -d, | \
    while read i ; do 	\
	if ! git grep -qw "$i" arch/arm/tools/mach-types ; then echo $i ; fi ;\
    done
M28EVK
KOTA2

The patch that Magnus did for the KOTA2  mach-types entry is currently
in the same state, waiting for an Ack from Russell.

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