Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider reorganizing repo directories #321

Closed
ayrtonm opened this issue Feb 29, 2024 · 3 comments
Closed

Consider reorganizing repo directories #321

ayrtonm opened this issue Feb 29, 2024 · 3 comments
Labels
ARM ARM related work documentation Improvements or additions to documentation Low priority

Comments

@ayrtonm
Copy link
Contributor

ayrtonm commented Feb 29, 2024

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.

@ayrtonm ayrtonm added documentation Improvements or additions to documentation Low priority ARM ARM related work labels Feb 29, 2024
@ayrtonm
Copy link
Contributor Author

ayrtonm commented Mar 1, 2024

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.

@ayrtonm
Copy link
Contributor Author

ayrtonm commented Mar 5, 2024

TODO: framework -> runtime, no top level include dir

@ayrtonm
Copy link
Contributor Author

ayrtonm commented Mar 15, 2024

Fixed by #322

@ayrtonm ayrtonm closed this as completed Mar 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ARM ARM related work documentation Improvements or additions to documentation Low priority
Projects
None yet
Development

No branches or pull requests

1 participant