Status of Servo on OpenHarmony and Oniro

[mukilan]

This issue collects the current set of issues blocking Servo from building & running on OpenHarmony and Oniro. Until now we have been hoping to use Rockchip (rk3568) board with OpenHarmony 3.2 (maybe upgrade to 4.0) as the eventual target, though all of the work below was done on an Ubuntu 20.04 VM.

Building servo/mozjs for OpenHarmony: Able to compile successfully with local patch to make configure script work

Building servo uncovered more issues, most of them due to lack of support for ohos target in third party rust crates:

1. socket2 needs patches for Iovlen type. GitHub ticket open but no progress.
2. The nix crate didn't compile as it uses C shm_open and and other functions from the shm_ family that OHOS chooses not to expose. We've patched it locally to follow the code in nix for android which also doesn't expose shm_*.
3. nix had many other compilation errors because nix doesn't handle target_env=ohos in conditionally compiled code. We've patched it locally so that code conditional on target_env=musl is now conditional on any(target_env=musl, target_env=ohos). A similar fix had to be done in socket2 crate as well. Seems like this was the correct approach.
4. Servo's components/allocator crate uses jemalloc-sys native library which doesn't support ohos triples in its configure script, so for now we've turned off the feature that uses jemalloc-sys.

The above local patches could potentially be contributed to upstream crates, but it is unclear what is the strategy for testing and reviewing the PRs should be.

5. Servo requires the 'rustc-dev' component of the toolchain since its script_plugin crate uses the rustc crate for compile time plugins. The prebuilt rustc toolchain doesn't include this component, but looks like this can be built using standard rust toolchain. The version of rustc that Servo uses is now quite old and doesn't include recent patches in upstream rust for ohos target. So we'll probably need to complete the rustc toolchain upgrade in servo before attempting this again.

Additionally, there are open questions that we've not yet started exploring such as integrating with native windowing system & OpenGL stack on OpenHarmony. We also have an issue on Servo side to track the status and collect issues that might not be relevant to OHOS/Oniro folks.

[Stefan-Schmidt]

Until now we have been hoping to use Rockchip (rk3568) board with OpenHarmony 3.2 (maybe upgrade to 4.0) as the eventual target, though all of the work below was done on an Ubuntu 20.04 VM.

I am currently looking into switching over to the 4.0 release branch (from 3.2 LTS). Most partners have expressed interest in the move. It will be a few days until I have it done and verified.

[Stefan-Schmidt]

The above local patches could potentially be contributed to upstream crates, but it is unclear what is the strategy for testing and reviewing the PRs should be.

With a view from Oniro getting these fixed upstream would be the preference. We would than need to follow up with the third_party components that import these to be updated. In cases where upstream is not willing to take the changes we can also consider adding them to the respective third_party component, but it's less preferred.

[Stefan-Schmidt]

Additionally, there are open questions that we've not yet started exploring such as integrating with native windowing system & OpenGL stack on OpenHarmony. We also have an issue on Servo side to track the status and collect issues that might not be relevant to OHOS/Oniro folks.

For this I would suggest to also have a chat with the engineers from SoftwareMansion (Oniro working group member company) who do the work on porting ReactNative. They should have experience in targeting the arkUI graphic system for proper integration.

[mukilan]

An update about the issue with rust toolchain - I attempted a fresh build of latest Servo, with some of my earlier patches. I also used the 4.1 beta version of OHOS SDK for this attempt.

1. It seems the -Zbuild-std flag needed to cross compile to OHOS target using standard rust toolchain is still an unstable feature. Since this is not available on stable rustc (Servo has since switched to stable rust), I had to continue the experiment with the closest nightly version to avoid code changes. With the nightly rustc and -Zbuild-std it looks like we are now unblocked on the toolchain side.
2. The compilation of Servo didn't complete successfully and it looks due to more changes in libc crate that have landed upstream, requiring more changes in the crates that depend on it, such as nix, which need to keep up with libc. I tried pinning the versions, but that broke other dependencies.

[matlu]

Promote OpenHarmony targets to tier 2 has now landed, see: https://github.com/rust-lang/rust/pull/120585 @mukilan @Stefan-Schmidt