You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CMake made the fundamental design choice to only support one toolchain per invocation which makes it slightly more annoying to add support for ARM. The issue is that we need to compile both arch-specific code and host tools. Luckily we have no mixed-arch directories but we do have places where nested subdirectories have different archs (e.g. repo root is native arch, rewriter is host, rewriter/tests is native). I already added support for this in #311 but since that PR already splits the config step into multiple CMake invocations using ExternalProject_Add I thought it would make sense to reorganize things a bit by arch before merging any ARM stuff anyway.
Also I'm updating the README/docs with an overview of the repo directory structure and I realized that the repo is a bit confusing to navigate. I propose reorganizing it as follows
cmake - no changes
docs - no changes
external - no changes
examples - no changes
framework (new top-level dir)
- libia2 (previously top-level libia2 dir)
- partition-alloc (previously top-level partition-alloc dir)
- move contents of scripts/partition_alloc here and remove top-level scripts dir
- this is still just our shim for PA, all the third-party code should remain in external/chromium
- process-tracer (previously top-level runtime dir)
tests (previously rewriter/tests dir)
tools (new top-level dir)
- rewriter (previously top-level rewriter dir)
- pad-tls (previously top-level pad-tls dir)
I'm very open to naming suggestions for the framework and process-tracer directories (and even libia2 but that would require more changes so I think we can keep it as-is for now). The idea is that framework (maybe sandbox?) includes anything that is part of a compartmentalized application (both in the process and for tracing it). Also I think we should rename runtime since we've sometimes used it to refer to things that are part of libia2.a or the call gates and I think some variation of "tracer" would be more descriptive.
The text was updated successfully, but these errors were encountered:
I could also see a case for naming the top-level framework dir lib instead (though it'd be a bit unexpected to have the tracer stuff there in that case). It might also make sense to move the things that are part of the compartmentalization "API" (e.g. IA2_FN, IA2_CALL, etc.) to a top-level include directory to make it more easily discoverable. This might also be easier to do after implementing #320 since that's a big reason why ia2.h currently should be a part of the libia2 directory even though most of the public API should not depend on it.
CMake made the fundamental design choice to only support one toolchain per invocation which makes it slightly more annoying to add support for ARM. The issue is that we need to compile both arch-specific code and host tools. Luckily we have no mixed-arch directories but we do have places where nested subdirectories have different archs (e.g. repo root is native arch,
rewriter
is host,rewriter/tests
is native). I already added support for this in #311 but since that PR already splits the config step into multiple CMake invocations usingExternalProject_Add
I thought it would make sense to reorganize things a bit by arch before merging any ARM stuff anyway.Also I'm updating the README/docs with an overview of the repo directory structure and I realized that the repo is a bit confusing to navigate. I propose reorganizing it as follows
I'm very open to naming suggestions for the
framework
andprocess-tracer
directories (and evenlibia2
but that would require more changes so I think we can keep it as-is for now). The idea is thatframework
(maybesandbox
?) includes anything that is part of a compartmentalized application (both in the process and for tracing it). Also I think we should renameruntime
since we've sometimes used it to refer to things that are part oflibia2.a
or the call gates and I think some variation of "tracer" would be more descriptive.The text was updated successfully, but these errors were encountered: