[OpenAFS-devel] Re: Compiling openafs on arm64/aarch64 architecture

Benjamin Kaduk kaduk@MIT.EDU
Mon, 27 Oct 2014 00:05:11 -0400 (EDT)


On Fri, 17 Oct 2014, Andrew Deason wrote:

> On Fri, 17 Oct 2014 14:07:31 -0700
> Micheal Waltz <mwaltz@qualcomm.com> wrote:
>
> > Reading the ARM docs it appears we should use the
> > aarch64-arm-none-eabi target, as using the armv8a-arm-none-eabi target
> > is the 32-bit state of armv8 [3]. I also am assuming we would want to
> > not disable fpu registers in order to avoid performance hits.
>
> That's common in kernel code, I thought; maintaining fpu state is added
> overhead and it's not commonly used. Unless the crypto stuff has some

Some registers are shared between the FPU and sse and/or mmx instructions
on some x86 systems, IIRC, so kernels wishing to use those instructions
must save/restore the FPU context around such uses.

> special handling to allow it to be used for performance reasons.
>
> > Unfortuantely I'm not sure where I can disable the use of the
> > -mgeneral-regs-only flag, as I don't see it in the Makefile or
> > configure as an option.
>
> You're compiling for the kernel, so it's likely coming from Linux; when
> building a kernel module, the Linux build system tells us what compiler
> flags to use (a lot of them, anyway). There might be a way to disable it
> from there if you look around, or maybe we just shouldn't be using a
> floating-point type (note that we're not actually using the data, from a
> brief glance).

We shouldn't really be using a floating-point type in the kernel, but
that's part of the RAND_add() API that hcrypto uses, and we don't apply
local patches to the bits in src/external, so we're stuck with fun things
like '#define double int64_t' in src/crypto/hcrypto/kernel/config.h.

crypto-rand.c, compiled into libafsrfc3961, has a call to RAND_add, but it
is not compiled in the kernel build, so the above #define should give a
self-consistent KBI for our kernel non-use, and the difference from the
userspace ABI should not cause problems.

That doesn't make it any more pretty, of course...

-Ben