From: Catalin Marinas <catalin.marinas@arm.com> To: Will Deacon <will.deacon@arm.com> Cc: Mark Rutland <Mark.Rutland@arm.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "ghackmann@google.com" <ghackmann@google.com>, "ijc@hellion.org.uk" <ijc@hellion.org.uk>, Serban Constantinescu <Serban.Constantinescu@arm.com>, "cross-distro@lists.linaro.org" <cross-distro@lists.linaro.org>, "linux-api@vger.kernel.org" <linux-api@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> Subject: Re: [RFC PATCH 0/1] arm64: Fix /proc/cpuinfo Date: Thu, 6 Nov 2014 17:05:48 +0000 [thread overview] Message-ID: <20141106170548.GF19702@e104818-lin.cambridge.arm.com> (raw) In-Reply-To: <20141106165430.GH31605@arm.com> On Thu, Nov 06, 2014 at 04:54:31PM +0000, Will Deacon wrote: > On Thu, Nov 06, 2014 at 04:43:12PM +0000, Catalin Marinas wrote: > > On Fri, Oct 24, 2014 at 02:56:39PM +0100, Mark Rutland wrote: > > > [d] Print different hwcaps dependent on the personality. > > > > > > This would allow for 32-bit and 64-bit applications to function > > > correctly, but for some 32-bit applications the personality would > > > need to be set explicitly by the user. > > > > Which makes this option actually in line with the uname -m behaviour. My > > vote goes for [d] with option [b] as a close alternative. > > > > > [1] arm, v3.17, Versatile Express A15x2 A7x3 coretile > > > Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm > > [...] > > > [2] arm64, v3.17, Juno platform > > > Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 > > > > As an exercise, I'm trying to see what option [b] would look like when > > CONFIG_COMPAT is enabled: > > > > Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae > > > > The duplicate strings would only be listed once (evtstrm, aes, pmull, > > sha1, sha2, crc32). New AArch64 features that we may expect to be > > optional on AArch32 could be prefixed with "a64". If they are missing > > entirely from AArch32, (like asimd), no need for the prefix. > > > > The advantage is that we don't need to check the personality but we have > > to assume that scripts would not search for substrings (sane people > > shouldn't do this anyway as the Features string can always be extended). > > And a big disadvantage is that I can imagine AArch64 applications checking > for "neon" instead of "asimd", which will break if they're run under kernels > without COMPAT support enabled. That's because they do stupid things and I they probably deserve to break ;). But I agree, there is a risk. > So I'm inclined to stick with Mark's patch as it is. If we don't hear otherwise, I propose sometime next week we queue Mark's patch for -next. -- Catalin
WARNING: multiple messages have this Message-ID (diff)
From: catalin.marinas@arm.com (Catalin Marinas) To: linux-arm-kernel@lists.infradead.org Subject: [RFC PATCH 0/1] arm64: Fix /proc/cpuinfo Date: Thu, 6 Nov 2014 17:05:48 +0000 [thread overview] Message-ID: <20141106170548.GF19702@e104818-lin.cambridge.arm.com> (raw) In-Reply-To: <20141106165430.GH31605@arm.com> On Thu, Nov 06, 2014 at 04:54:31PM +0000, Will Deacon wrote: > On Thu, Nov 06, 2014 at 04:43:12PM +0000, Catalin Marinas wrote: > > On Fri, Oct 24, 2014 at 02:56:39PM +0100, Mark Rutland wrote: > > > [d] Print different hwcaps dependent on the personality. > > > > > > This would allow for 32-bit and 64-bit applications to function > > > correctly, but for some 32-bit applications the personality would > > > need to be set explicitly by the user. > > > > Which makes this option actually in line with the uname -m behaviour. My > > vote goes for [d] with option [b] as a close alternative. > > > > > [1] arm, v3.17, Versatile Express A15x2 A7x3 coretile > > > Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm > > [...] > > > [2] arm64, v3.17, Juno platform > > > Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 > > > > As an exercise, I'm trying to see what option [b] would look like when > > CONFIG_COMPAT is enabled: > > > > Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae > > > > The duplicate strings would only be listed once (evtstrm, aes, pmull, > > sha1, sha2, crc32). New AArch64 features that we may expect to be > > optional on AArch32 could be prefixed with "a64". If they are missing > > entirely from AArch32, (like asimd), no need for the prefix. > > > > The advantage is that we don't need to check the personality but we have > > to assume that scripts would not search for substrings (sane people > > shouldn't do this anyway as the Features string can always be extended). > > And a big disadvantage is that I can imagine AArch64 applications checking > for "neon" instead of "asimd", which will break if they're run under kernels > without COMPAT support enabled. That's because they do stupid things and I they probably deserve to break ;). But I agree, there is a risk. > So I'm inclined to stick with Mark's patch as it is. If we don't hear otherwise, I propose sometime next week we queue Mark's patch for -next. -- Catalin
next prev parent reply other threads:[~2014-11-06 17:06 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-10-24 13:56 [RFC PATCH 0/1] arm64: Fix /proc/cpuinfo Mark Rutland 2014-10-24 13:56 ` Mark Rutland 2014-10-24 13:56 ` Mark Rutland 2014-10-24 13:56 ` [RFC PATCH 1/1] arm64: Fix up /proc/cpuinfo Mark Rutland 2014-10-24 13:56 ` Mark Rutland 2014-10-24 13:56 ` Mark Rutland 2014-10-30 17:15 ` Will Deacon 2014-10-30 17:15 ` Will Deacon 2014-10-30 17:15 ` Will Deacon 2014-10-30 17:20 ` Ian Campbell 2014-10-30 17:20 ` Ian Campbell 2014-10-30 17:20 ` Ian Campbell 2014-10-24 14:19 ` [RFC PATCH 0/1] arm64: Fix /proc/cpuinfo Russell King - ARM Linux 2014-10-24 14:19 ` Russell King - ARM Linux 2014-10-24 14:19 ` Russell King - ARM Linux 2014-10-24 14:24 ` Mark Rutland 2014-10-24 14:24 ` Mark Rutland 2014-10-24 14:24 ` Mark Rutland 2014-10-24 15:42 ` Russell King - ARM Linux 2014-10-24 15:42 ` Russell King - ARM Linux 2014-10-24 15:42 ` Russell King - ARM Linux 2014-10-28 4:43 ` Greg Hackmann 2014-10-28 4:43 ` Greg Hackmann 2014-11-06 16:43 ` Catalin Marinas 2014-11-06 16:43 ` Catalin Marinas 2014-11-06 16:43 ` Catalin Marinas 2014-11-06 16:54 ` Will Deacon 2014-11-06 16:54 ` Will Deacon 2014-11-06 16:54 ` Will Deacon 2014-11-06 17:05 ` Catalin Marinas [this message] 2014-11-06 17:05 ` Catalin Marinas 2014-11-06 17:05 ` Catalin Marinas 2014-11-13 17:48 ` Catalin Marinas 2014-11-13 17:48 ` Catalin Marinas 2014-11-13 17:48 ` Catalin Marinas
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20141106170548.GF19702@e104818-lin.cambridge.arm.com \ --to=catalin.marinas@arm.com \ --cc=Mark.Rutland@arm.com \ --cc=Serban.Constantinescu@arm.com \ --cc=cross-distro@lists.linaro.org \ --cc=ghackmann@google.com \ --cc=ijc@hellion.org.uk \ --cc=linux-api@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.