<snip> > > >> > > >> > 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). > > > Yes, users can do multi-arch checks *locally* by using qemu. > This patch aims to enable *public* CI for aarch64. It has no sense to rely on > specific arch while infrastructure supports multi arch. > > > > 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). > > > It is more like a tool for local validation, and should be another story. > > > >> 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? > > > Yes, over half of quick tests can run in no-huge environment. Plan is to enable the testing for whatever works today and work on fixing the remaining test cases. Is this ok?
<snip>
