[PATCH 0/4] arm64: advertise availability of CRC and crypto instructions
Nicolas Pitre
nicolas.pitre at linaro.org
Wed Dec 18 14:57:00 EST 2013
On Wed, 18 Dec 2013, Ard Biesheuvel wrote:
> On 18 December 2013 15:27, Christopher Covington <cov at codeaurora.org> wrote:
> >
> > I do not think that Russell is the source of the confusion. Ard wrote, "The
> > idea is that a binary built for ARM will have access to the extended
> > instructions which ARM64 offers to ARM32 binaries running in 32 bit
> > compatibility mode (such as AES, SHAx etc)." I think s/ARM64/ARMv8/ is
> > necessary to make the statement correct, and hopefully less confusing.
> >
>
> My apologies for adding to the confusion (or creating it in the first place).
>
> However, the bottom line is that, as the 32 bit and 64 bit kernels are
> both able to support userland processes running in the execution state
> that has retroactively been dubbed 'AArch32', they should both honor
> the same contract with AArch32 userland on how to discover CPU
> capabilities at runtime. I do understand Russell's reservations about
> allocating 6 of the remaining 10 hwcaps bits, and I am open to
> suggestions on a better approach.
What is the reason for eating a grand total of 6 bits at once in the
first place?
Are those capabilities really going to be independently integrated? In
other words, what is the probability for a vendor to integrate some but
not the others? If this probability is low then maybe a smaller set of
wider-covering bits would be good enough in practice, and then some
kernel emulation could be added for the odd cases.
Nicolas
More information about the linux-arm-kernel
mailing list