Honnappa Nagarahalli <honnappa.nagaraha...@arm.com> writes: > <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?
Sounds good then. > <snip>
