Partition / fs layout for Oniro OpenHarmony

added to epic &55

changed milestone to %goofy alpha

set weight to 7

changed the description

added teamopenharmony label

changed iteration to Oniro Core Iterations Apr 1, 2022 - Apr 30, 2022

added Doing label

I have been looking at library paths / layout.

OpenHarmony places libraries in /system/lib, and uses a non-standard .z.so file extension for shared libraries. Example: /system/lib/libhdi_audio_interface_lib_render.z.so

For better integration with Oniro, we want to place libraries in the standard /usr/lib location, and use standard library file names, meaning ABI versioned .so files. Example: /usr/lib/liblz4.so.1.9.3 with symlinks to it from /usr/lib/liblz4.so.1 and /usr/lib/liblz4.so.

In OpenHarmony code, there is hardcoded usage of the OpenHarmony library paths. Both in framework code and in ACTS test cases. In order to avoid patching code, and to not break ACTS, we could setup symlinks from /system/lib/*.z.so files to the corresponding library files in /usr/lib.

assigned to @esben

We will go with a simple solution for library and executable files. Everything that OHOS places in /system/lib we place in /usr/lib, and then we setup /system/lib as symlink to /usr/lib. That way we don't have to tinker with runtime library paths, and hard-coded /system/lib paths in OpenHarmony code will not break (yes, there is plenty of such hard-coded paths).

The same for executable files. Install to /usr/bin and then setup /system/bin as symlink to that.

So the general idea is to install all files to normal Linux paths, and then setup the needed symlinks in /system to trick OpenHarmony code to find files in their hardcoded paths, so we don't have to patch up the code.

Right now we have this implemented for /system/lib and /system/bin, and we will do the same for stuff such as /system/etc and /system/profile.

closed with merge request eclipse/oniro4openharmony/meta-openharmony!1 (merged)

removed Doing label