linux-kernel - Re: [GIT PULL] UniCore32 ISA support for linux-2.6

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]

Message-Id: <201102122011.34664.arnd@arndb.de>
Date:	Sat, 12 Feb 2011 20:11:34 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Guan Xuetao <gxt@...c.pku.edu.cn>, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] UniCore32 ISA support for linux-2.6

On Saturday 12 February 2011 18:51:32 Linus Torvalds wrote:
> On Fri, Feb 11, 2011 at 5:32 PM, Guan Xuetao <gxt@...c.pku.edu.cn> wrote:
> > Hi Linus,
> >  Could you please pull from:
> >    git://git.kernel.org/pub/scm/linux/kernel/git/epip/linux-2.6-unicore32.git for_linus
> >  to add unicore32 support for linux-2.6.
> 
> I'm not going to do it during the 38 cycle, but if this has has gotten
> ack's from people like Arnd, and all the commentary from other people
> (like the "the ptrace.c file looks like it was copied from arm, wants
> attribution" etc), I can pull it in the 39 cycle.

I think it should still be posted once more to linux-arch/linux-kernel
as emails. I gave an Acked-by to a number of patches that are
harmless and that I didn't have any comments on.

There are a number of patches that I reviewed more thoroughly, and
Guan did a good job of cleaning up the code based on that. I believe
it's basically good to go into 2.6.39 once they go over the mailing
list in the current version. I'll reply with a Reviewed-by tag to the
patches that I reviewed and that now look ok when that happens.

There are a few remaining issues from the review, which can probably
be addressed in a later version. For instance, I suggested the use
of a flattened device tree for enumerating the nondiscoverable
SoC devices, which should help long-term maintainance, but is not
essential.

I should probably have been clearer about the timing for merging.
While I must have mentioned it at some point, there were a lot of
things I needed to explain about the process, so it probably
got lost.

> Arnd - who else was involved in the reviews? Is there somebody who
> should have been involved and wasn't?

A few people commented on specific patches, but I don't think anyone
besides me looked at all of it. Greg and others reviewed the
device drivers, so I did not bother with those.

I don't know enough about the signal handling code to do a good review,
and I tried to get Al Viro involved at some point, but didn't get his
attention.

	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/