Ruifeng Wang <ruifeng.w...@arm.com> writes:

>> -----Original Message-----
>> From: Aaron Conole <acon...@redhat.com>
>> Sent: Monday, January 6, 2020 21:34
>> To: Ruifeng Wang <ruifeng.w...@arm.com>
>> Cc: maicolgabr...@hotmail.com; tho...@monjalon.net;
>> ferruh.yi...@intel.com; arybche...@solarflare.com; dev@dpdk.org;
>> david.march...@redhat.com; Gavin Hu <gavin...@arm.com>; Honnappa
>> Nagarahalli <honnappa.nagaraha...@arm.com>; nd <n...@arm.com>
>> Subject: Re: [PATCH v3 2/2] ci: add travis ci support for aarch64
>> 
>> Ruifeng Wang <ruifeng.w...@arm.com> writes:
>> 
>> > Add Travis compilation jobs for aarch64. gcc/clang compilations for
>> > static/shared libraries are added.
>> >
>> > Some limitations for current aarch64 Travis support:
>> > 1. Container is used. Huge page is not available due to security reason.
>> > 2. Missing kernel header package in Xenial distribution.
>> >
>> > Solutions to address the limitations:
>> > 1. Not to add unit test for now. And run tests with no-huge in future.
>> > 2. Use Bionic distribution for all aarch64 jobs.
>> >
>> > Signed-off-by: Ruifeng Wang <ruifeng.w...@arm.com>
>> > Reviewed-by: Gavin Hu <gavin...@arm.com>
>> > ---
>> 
>> Can't we achieve the same thing by setting
>> 
>> arch:
>>   - amd64
>>   - arm64
>> 
>> in the build matrix?  Or will that also force the intel builds to use the 
>> container
>> infrastructure (in which case the no-huge support needs to be fixed)?
>
> No, container infrastructure will not be imposed to intel builds. 
> AFAIN, Travis infrastructure for a specific CPU arch is provided as
> is, and there is no config option to control.
> The problem with just adding 'arch' in build matrix is that RUN_TESTS on 
> arm64 is not supported
> by now (Travis limitation). 'env' with RUN_TESTS will fail.

Okay I see.

>> 
>> One thing I wonder, isn't is possible to use qemu-user to do the amd64 unit
>> tests?  Then do we really need some changes to do the native build?
>
> Do you mean to use qemu-user to do unit tests for non-x86 arch?

Yes.  This has the advantage of giving users a way to also do the
multi-arch checks on their own systems (so a developer with just an x86
could at least do some testing on arm or ppc).

> Changes will be needed as well to enable qemu-user to do unit test.
> Since Travis support multi CPU arch, I think native build and test is simpler 
> and more natural. 

I agree, some script changes might be needed, but maybe not as many as
you fear (can't we use binfmt_misc infrastructure to do this with
qemu-user and then the actual 'execute' would work).

>> Does it buy us anything *today* given the cost of the hugepage restriction?
>> Will that ever be resolved (I didn't see so from the docs on travis)?
>
> The hugepage issue has been reported to Travis. I think it will be
> resolved. But no set dates yet.

Is there a plan for them to address?  I guess probably not.  So we
either need the ability for tests to run in the no-huge environment (and
detect that no hugepages are available to run the tests that way), or we
need the travis environment supporting hugepages.  Is there something I
missed?

>> 
>> >  .ci/linux-setup.sh | 11 +++++++----
>> >  .travis.yml        | 42 +++++++++++++++++++++++++++++++++++++++++-
>> >  2 files changed, 48 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh index
>> > dfb9d4a20..a92978037 100755
>> > --- a/.ci/linux-setup.sh
>> > +++ b/.ci/linux-setup.sh
>> > @@ -3,7 +3,10 @@
>> >  # need to install as 'root' since some of the unit tests won't run
>> > without it  sudo python3 -m pip install --upgrade meson
>> >
>> > -# setup hugepages
>> > -cat /proc/meminfo
>> > -sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
>> > -cat /proc/meminfo
>> > +# hugepage settings are skipped on aarch64 due to environment
>> > +limitation if [ "$TRAVIS_ARCH" != "aarch64" ]; then
>> > +    # setup hugepages
>> > +    cat /proc/meminfo
>> > +    sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
>> > +    cat /proc/meminfo
>> > +fi
>> > diff --git a/.travis.yml b/.travis.yml index 8f90d06f2..980c7605d
>> > 100644
>> > --- a/.travis.yml
>> > +++ b/.travis.yml
>> > @@ -115,6 +115,46 @@ matrix:
>> >        apt:
>> >          packages:
>> >            - *extra_packages
>> > -
>> > +  - env: DEF_LIB="static"
>> > +    arch: arm64
>> > +    compiler: gcc
>> > +    dist: bionic
>> > +    addons:
>> > +      apt:
>> > +        packages:
>> > +          - *required_packages
>> > +  - env: DEF_LIB="shared"
>> > +    arch: arm64
>> > +    compiler: gcc
>> > +    dist: bionic
>> > +    addons:
>> > +      apt:
>> > +        packages:
>> > +          - *required_packages
>> > +  - env: DEF_LIB="static"
>> > +    arch: arm64
>> > +    dist: bionic
>> > +    compiler: clang
>> > +    addons:
>> > +      apt:
>> > +        packages:
>> > +          - *required_packages
>> > +  - env: DEF_LIB="shared"
>> > +    arch: arm64
>> > +    dist: bionic
>> > +    compiler: clang
>> > +    addons:
>> > +      apt:
>> > +        packages:
>> > +          - *required_packages
>> > +  - env: DEF_LIB="shared" OPTS="-Denable_kmods=false" BUILD_DOCS=1
>> > +    arch: arm64
>> > +    compiler: gcc
>> > +    dist: bionic
>> > +    addons:
>> > +      apt:
>> > +        packages:
>> > +          - *required_packages
>> > +          - *doc_packages
>> >
>> >  script: ./.ci/${TRAVIS_OS_NAME}-build.sh

Reply via email to