ubuntu-phone team mailing list archive

[Simon Fels <simon.fels@xxxxxxxxxxxxx>]

On 14.09.2015 13:12, John McAleely wrote:
> I like the sound of multiarch for two reasons:
>
>   - It trivially guarantees compatibility for all the apps in the store today
>   - It allows us to make use of 64 bit whenever it is useful
>
> If we forgo the second advantage, we could just boot the kernel & android
> container in 64 bit, and continue booting Ubuntu as a 32bit system. I've
> documented this in a diagram here:
>
> https://wiki.ubuntu.com/Touch/ContainerArchitecture
>
> in the section: "mixed-containers, 32bit Ubuntu, 64bit Android". It seems
> this would enable us to start using 64bit Android BSPs as a device specific
> feature of the device tarball, and then we can migrate Ubuntu to 64bit or
> multiarch at a time of our own choosing (ie, we're not dictated to by the
> availability of android BSPs).
>
> Unless there's any reason this scheme shouldn't work, I would like to
> propose it as the initial way we use 64bit android BSPs.

That is fine for me.

However as soon as we can't provide something we have to load through 
hybris and don't provide as a binder-accessible service on the container 
side we need a 64-bit version of libhybris and also 64 bit versions of 
those services on the Ubuntu side which are using those bits.

Small example (not very likely to happen but to highlight what we might 
end up with):

Android has a HAL lights module which is loaded by our powerd through 
libhybris. Means once the lights module is only available as 64 bit only 
(we only get a binary from the vendor, ...) we have to load it as 64 bit 
through hybris into powerd which brings us to the multiarch system with 
a 64 bit powerd.

I am not sure if we have those intersection points with the Android 
container documented but if not we should really do that to have an 
better overview for further decisions and possible requirements we put 
out for compatible Android BSPs.

regards,
Simon