Re: [PATCH v2] arm64: compat: Implement misalignment fixups for multiword loads
I do know that you do not like my comment that 32bit on Pi4
is much more efficient than 64 Bit ...
Linadmin
On 17.08.22 11:47, Arnd Bergmann wrote:
> On Tue, Aug 16, 2022 at 10:29 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>> Thanks for chiming in.
>>
>> At this point, it is really up to the maintainers to decide whether
>> the maintenance burden is worth it. The code itself seems pretty
>> uncontroversial afaict.
>>
>> Might other distros be in a similar situation? Or is this specific to Debian?
> My guess is that this is the most prominent on Debian: Many others including
> have discontinued or reduced support for 32-bit builds across architectures:
> Ubuntu only supports "Core" with fewer packages on Raspberry Pi 2 but
> not desktop or server, Opensuse Leap and Tumbleweed both distributes a
> lot of board specific images but you have to know where to look as the main
> page only advertises amd64/i686/arm64/ppc64le/s390x, Fedora stopped
> entirely.
>
> Android may be an interesting distro here: there are still a lot of phones
> running a pure 32-bit userland on Cortex-A53/A55 CPUs, and there are a
> large number of applications built for this. As far as I can tell, they tend to
> run 32-bit kernels as well, but that is not going to work on newer processors
> starting with Cortex-A76 big cores or Cortex-A510 little cores.
>
> archlinuxarm supports 32-bit and 64-bit machines equally, but they
> apparently avoid the build service problem by using distcc with
> x86-to-arm cross compilers, and they don't seem to support
> their 32-bit images on 64-bit hardware/kernel.
>
> https://hub.docker.com/search?q=&source=verified&type=image&architecture=arm&image_filter=official
> lists 98 "official" arm32 images plus countless ones in other categories.
> I think these are popular in memory-constrained cloud hosting
> setups on arm64, so the Alpine based images are probably the most
> interesting ones because of their size, but they would run under
> someone else's kernel.
>
> Arnd
>
Reply to: