linux-kernel - Re: [PATCH 00/36] AArch64 Linux kernel port

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: <20120710165746.GB20221@arm.com>
Date:	Tue, 10 Jul 2012 17:57:46 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Ingo Molnar <mingo@...nel.org>, Arnd Bergmann <arnd@...db.de>,
	Olof Johansson <olof@...om.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Russell King <linux@....linux.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 00/36] AArch64 Linux kernel port

On Tue, Jul 10, 2012 at 04:33:58PM +0100, Alan Cox wrote:
> > In the AArch32 kernel port many implementation decisions newer
> > architectures were made in a way that preserves backwards compatibility
> > to over 15 years ago (and for *good* reasons, ARMv4 hardware is still in
> > use). But keeping the same decisions in AArch64 is wrong.
> 
> Same argument as x86-32 v x86-64. Same issues about compatibility.

I don't deny that the arguments may be the same (I should go back and
read those threads). The AArch64 context is different and we can't do a
comparison with the x86 case.

> > AArch64 is also in its early days with a lot of developments to come
> > (and still waiting for hardware). Until we really know the final shape,
> > the AArch64 code base must allowed to evolve independently from the
> > AArch32 one.
> 
> That is one area where while the merge was needed and a lot of work the
> original split may well have been sensible for x86-64 as well.

That's exactly why I don't see the point in arguing whether the current
AArch64 port should be merged into arch/arm/.

> > The initial target is servers (see the companies that have announced
> > plans around ARMv8) but I agree, we may see it in other devices in the
> > future. But as the maintainer I have no plans to support a 32-bit SoC on
> > an AArch64/ARMv8 system (which may or may not support AArch32 at kernel
> > level). If an AArch64 SoC would share some devices with an AArch32 SoC,
> > such code will go to drivers/.
> 
> What plans to other maintainers and board vendors have ? Any design choice
> has to cope with these happening if a third party goes and does it.

Very few vendors (or architecture licensees) went public on this, so
cannot speak for their plans. But there are ongoing private discussions
on standardising relevant parts of the SoC, having a common firmware API
for CPU booting, possibly using ACPI. Again, it's early development
stage.

If a third party tries to push a 32-bit ARMv8 SoC port, I rely on the
arm-soc team (Arnd, Olof) to reject it. It's similar to the argument
against people running a 32-bit kernel on x86_64 hardware. The main
reason we have 32-bit at the EL1 (kernel) level is for virtualisation
where one may want to run a 32-bit guest OS.

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