spl23 wrote: ↑
Mon May 28, 2018 10:50 am
At present we are able to ship one OS image that will run on every Pi ever sold; if we were to produce a 64-bit image, we would either orphan Pi 0 and PI 1 devices, or we would need to build, maintain and support two different images, with the attendant potential for actual confusion between them.
I think the point of this thread is that the existing 32-bit user land works fine with a 64-bit kernel. The foundation already maintains separate ARMv6 and ARMv7 kernels. Why not a 64-bit ARMv8 kernel a well? That should be easier and more compatible than maintaining a separate image with a full 64-bit user land.
As already mentioned, most desktop and server software is developed and tested in 64-bit environments these days. Few developers use 32-bit machines to test on, have the time or even care. Except for the sysbench CPU test, the problem is not so much the performance of the Pi in 32-bit mode but the difficulty of even compiling recent web browsers, video editors and databases.
How much C code do you see that still includes the far and near pointers needed for compatibility with the 16-bit segmented Intel 8086, 80186 and 80286 architectures? Do you think any current project would accept patches to put the far and near pointers back in? At some point in time developers will also stop pulling 32-bit compatibility patches into their projects. This is already the case with Firefox.
Once a 64-bit kernel is in place, it does not take much more to add a few optional 64-bit binaries where needed. Those binaries obviously wouldn't run on a 32-bit kernel, but there are already similar issues with the Java binaries in Raspbian that don't run on ARMv6 right now. For me the question is, why not simply add a 64-bit ARMv8 kernel to the existing Raspbian image?