It makes more sense to keep constants.json in the minijail package,
because that's where the tool that consumes it,
compile_seccomp_policy, lives. By having it in this package, we can
set it as the default location for compile_seccomp_policy, which means
it shouldn't ever even need to be specified on the command
line (although it still can be). And we can hook into the
cross-compilation machinery to get it to automatically use the
constants for the right architecture.
I've also changed from generating constants.json by running a test
program in qemu-user to generating it from LLVM IR, which will save a
huge QEMU build dependency.
This is a syscall table used for compiling Minijail policy files to
BPF. The compiler is available in the minijail-tools package. The
file is generated by compiling and running a small program named
dump_constants.
When cross-compiling, we have to get the syscall table for the host
platform. To do this, dump_constants is run under QEMU user emulation
for the appropriate platform. Google takes the same approach in their
minijail packages for ChromiumOS[1].
[1]: 729bd4269a/chromeos-base/minijail/minijail-9999.ebuild (49)
This is built from the same source as minijail, but is for all intents
and purposes a seperate package. It builds different things, with no
overlap, and is under a different license.
This is only the easy cases -- some fetchgit uses that point to
Gitiles instances are in generated code, where the generating code
would have to know in advance if it was fetching from Gitiles or not.
I don't think this is worth it.
