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

Consolidate FFI bindings #371

Open
Ralith opened this issue Mar 11, 2024 · 5 comments
Open

Consolidate FFI bindings #371

Ralith opened this issue Mar 11, 2024 · 5 comments
Assignees
Labels
enhancement New feature or request

Comments

@Ralith
Copy link

Ralith commented Mar 11, 2024

aws-lc-sys exposes separate bindings for every supported target. These files are huge, totaling almost 8MiB today and growing to 14MiB after #369. They are also almost identical to eachother: e.g. diff -U3 linux_aarch64_crypto.rs linux_x86_64_crypto.rs reveals that the only difference is the representation of the va_list argument to OPENSSL_vasprintf.

Most Rust FFI bindings are able to support diverse platforms using a single in-tree binding file (perhaps generated by bindgen with allowlisted symbols), leaving platform-specific types to be supplied by std::os::raw and/or libc, or at worst a small hand-written helper module. Can aws-lc-sys do similar?

@justsmth
Copy link
Contributor

Thanks for your feedback. I agree that these bindings files are huge, and their size grows linearly with the number of platforms that we pre-generate them for.

Although the size of the bindings will nearly double for 0.14.0, the bindings are just a small part of the crate contents. From my testing, the size of the aws-lc-sys crate will be increasing from ~6.8 MB compressed (~45 MB uncompressed) for 0.13.3 to ~7.5 MB compressed (~52 MB uncompressed) for 0.14.0. So, this will roughly be a 15% increase in the overall crate size.

We are open to ideas or suggestions on how to improve our bindings or improve the way they're generated. Unfortunately, considering the size of the AWS-LC API and the fact that it's still evolving, it would be too laborious and error-prone to maintain the bindings manually. Is there a tool that might automate the consolidation of very similar Rust source files (like linux_aarch64_crypto.rs and linux_x86_64_crypto.rs) in a way that preserved their platform-specific differences? That would be great!

@justsmth justsmth self-assigned this Mar 12, 2024
@justsmth
Copy link
Contributor

One possibility is to parse the various Rust bindings files, consolidating the types/values common to all into a single source file, leaving only what's unique to a platform in its respective platform-specific file that would be include!-ed.

@justsmth justsmth added the enhancement New feature or request label Mar 12, 2024
@justsmth
Copy link
Contributor

justsmth commented Mar 12, 2024

Simple change to help reduce space -- we could disable the "layout tests" for the bindings we publish in the crate: https://github.com/aws/aws-lc-rs/blob/main/aws-lc-sys/builder/bindgen.rs#L120

@camshaft
Copy link
Collaborator

Seems like we're including the libssl symbols as part of the pregenerated bindings as well. That seems unnecessary, especially since the primary purpose here is a libcrypto replacement.

@justsmth
Copy link
Contributor

We made some progress on this recently. As of our v1.9.0 release (i.e., aws-lc-sys v0.21), we no longer pregenerate the binding for the libssl library as part of the crate.

As mentioned above, there are still other steps we could take to further reduce the size of the pregenerated bindings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants