On 4/11/23 19:14, przemek klosowski via devel wrote:
On 4/4/23 10:28, Dan Čermák wrote:
Chris Adams <linux@xxxxxxxxxxx> writes:
Yeah, it'd be back to the i386/i586/i686 days... which was a bit of a
PITA sometimes. But cramming multiple architectures of core libraries
into a single RPM would be bad for disk space, image size, downloads,
etc.
But something that didn't exist in the i386/i686 days is containers -
whether base images like for podman or full things like Flatpaks.
Before going too deep into multi-level architectures, that should be
taken into account.
Afaik at least container runtimes do not support really support x86_64
subarchitectures: https://github.com/containers/podman/discussions/15256
The situation in the RISC-V universe is even more complicated because of
all the extensions
https://en.wikichip.org/wiki/risc-v/standard_extensions
It'll be challenging to write and package software that is portable
between all those variants---the fat binaries are just not practical due
to combinatorial complexity, so it'll have to be either install-time or
link-time configuration.
Whatever standard scheme Fedora uses for x86 will hopefully be very
useful for RiSC-V era that is apparently coming, with Linux-capable SBC
boards like VisionFive ($65) and Pine64 ($70 and $8 (!) ox64) just
becoming available, and a lot of activity on the horizon.
Rather than trying to track all the individual extensions and
combinations thereof, I would suggest focusing on RVI defined profiles.
Essentially they provide a set of mandatory features the architecture
must support (to be compliant with the profile).
That may rule out certain processors, but it ultimately provides a
higher performing baseline architecture for systems that are (hopefully)
going to be good performing parts rather than embedded focused parts.
jeff
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
