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

Isolate platform specific changes to their own crates #81

Closed
dreemkiller opened this issue Feb 11, 2021 · 3 comments · Fixed by #619 or #628
Closed

Isolate platform specific changes to their own crates #81

dreemkiller opened this issue Feb 11, 2021 · 3 comments · Fixed by #619 or #628
Assignees
Labels
always-refactoring A refactoring/code quality change to the Veracruz codebase build-process Something related to the Veracruz build process enhancement New feature or request repository Something related to management of the repository trusted-veracruz-runtime Something related to the trusted Veracruz runtime

Comments

@dreemkiller
Copy link
Member

Requested feature
Currently, all supported isolate technologies are supported by the Sinaloa and Mexico City crates, with features enabled or disabled to support the specific technology.

This has resulted in a confused build process. It also means that the work of adding support for future technologies will create merge conflicts and further complicate the building of these crates.

We should create separate crates for the non-secure side of each of the supported technologies, as well as for the secure-side. This would effectively split out the platform-specific parts of Sinaloa and Mexico City into multiple, platform-specific crates.

Motivation

The current use of features results in code and build processes that are hard to understand and hard to follow. Also, development of support for new platforms is likely to create difficult merge conflicts with other work.

It is desirable to have new platform support to be added (either inside this repository or outside of it) independently of the rest of the work happening on the project.

Additional context
This is likely to have knock-on effects elsewhere in the code base. For example, veracruz-utils has features to enable support for various platforms. It might be beneficial to have a utils-common, and a utils-* crate for each supported platform (or at least those that need platform-specific utilities).

@dreemkiller dreemkiller added the enhancement New feature or request label Feb 11, 2021
@nspin
Copy link
Member

nspin commented Mar 7, 2021

Needless to say, this would greatly simplify the task of adding support for a new isolate platform for someone who isn't already familiar with the entire source.

When porting to seL4, I found myself greping through the source for cfg attributes to find out what functionality I needed to implement. This improvement would define a clear interface between the platform-independent and platform-dependent code.

@dominic-mulligan-arm
Copy link
Member

Hopefully, with the "great renaming" almost being complete, this splitting can begin in the next week.

@dreemkiller
Copy link
Member Author

Was accidentally closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
always-refactoring A refactoring/code quality change to the Veracruz codebase build-process Something related to the Veracruz build process enhancement New feature or request repository Something related to management of the repository trusted-veracruz-runtime Something related to the trusted Veracruz runtime
Projects
None yet
4 participants