ubuntu-phone team mailing list archive

[Vicamo Yang <vicamo.yang@xxxxxxxxxxxxx>]

On Tue, Sep 8, 2015 at 12:54 PM, Simon Fels <simon.fels@xxxxxxxxxxxxx>
wrote:

> On 07.09.2015 17:21, Oliver Grawert wrote:
>
>> Am Montag, den 07.09.2015, 14:57 +0100 schrieb John McAleely:
>>
>>
>>> Are these the two options we have? What pros and cons are there for
>>> each?
>>>
>>
>> do you actually know (did anyone test) if hybris would get along with
>> running in 32bit on the ubuntu side while the container is 64bit ? i
>> suspect there needs to be some syscall translation between the two
>> hybris sides ...
>>
>
> I doubt that will work. At least not for libGLES, libEGL, .. as they don't
> use proper length-defined types like uint16_t. Also from what I've seen we
> can't promise which HAL libraries we get in 32 / 64 bit and which only in
> 32 bit and which only in 64 bit. The Android CDT defines a small subset of
> Android libraries which must be available in both variants but that isn't
> enough for our purpose. Also I am not entirely sure if the HAL API is
> reliable in terms of well defined types.
>

Most of the Android BSP libraries has both 32 and 64 bit builds on aarch64
if LOCAL_32_BIT_ONLY is not specified. libmediaplayerservice [1] is one of
the exceptions. HAL modules usually come with both versions, too. But
sometimes there is no 32 bit NFC module, and sometimes no 64 bit bluetooth
and camera modules. libGLES, libEGL and all the libs that are required by
app_process{32,64} must have both 32 and 64 bit versions because you need
app_process32 to exist in 64 bit android to launch 32 bit apps.

32 bit libhybris links 32 bit Android/Ubuntu libraries, and 64 bit
libhybris links 64 bit Android/Ubuntu libraries. They are not
interchangable.


>
> otherwise yes, it would be a good interim if we could use a 32bit rootfs
>> with 64bit container ... apps wouldnt be able to address the full ram
>> though (afaik thats limited to 3GB with armhf) so it wouldnt be a
>> permanent solution.
>>
>> long term someone needs to make arm64 images work anyway indeed.
>>
>
> For the near term we need a solution to handle both as we will have to
> support applications having different types at the moment. We need to find
> a way to ensure that all future applications in the store will get a 64 bit
> variant as well to prevent us from having to support 32 bit apps forever
> and can easily switch to 64 bit only later once we don't offer any other
> devices anymore.
>

> regards,
> Simon
>

[1]:
https://android.googlesource.com/platform/frameworks/av/+/android-5.0.2_r3/media/libmediaplayerservice/Android.mk


-- 
Vicamo Yang