On Fri, Apr 14, 2023 at 10:01 PM Jeff Law <jeffreyalaw@xxxxxxxxx> wrote: > > > > On 4/12/23 10:08, przemek klosowski via devel wrote: > >> > >> 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. > > > > Yes, good point, but there's already a number of profiles even though > > they are barely out of the gate: > > > > https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc > I know. While I'm not involved in setting the profiles, I do get > briefed on them reasonably often. > > > > > I of course agree with you that it makes sense to focus support on a > > small number of existing platforms with good reputation and performance > > (for instance both VisionFive and Pine64 are based on StarFive JH7110 SoC). > Those are not particularly interesting in my mind for a distro target. > If it can't run a performant system I'd put on my desk or in my rack, > then it's an embedded target in my mind (yes, I'm over-generalizing). > There's a place for those, but I don't think that should be Fedora's > focus for RISC-V. > > Full disclosure. I work for Ventana and have a long history with Red > Hat and Fedora. My vision for Fedora going back before it was actually > launched as for a desktop/developer focused distribution similar to RHL, > but free -- and as a feeder distribution into what was then known as > Advanced Server, now RHEL. > We should not screw up with RISC-V in Fedora like RHEL did with ARM. Yes, I'm saying RHEL's ARM strategy was a mistake, and still is, to some degree. We see aspects of this being walked back now as the ecosystem didn't go the way RHEL ARM folks hoped, and breaking further into that ecosystem requires reversing some of those choices. We should learn from that for Fedora RISC-V. Like ARM, RISC-V risks (pun intended!) total stratification between low/mid range SBCs and unobtanium servers. Given the current path of the groups working in RISC-V, this is certain to happen. Thus, if Fedora RISC-V cannot run well on RISC-V SBCs, then we effectively have no useful RISC-V port, since nobody can use it. We already have similar problems with POWER (ppc64le) and Z (s390x), but the former was built in an era when there were computers of reasonable performance across all price points. The latter is basically funded by IBM development and nobody can really do anything with it. For the first time in a long time, Fedora has the opportunity to have a first-mover advantage and become the default platform for hobbyist, professional, and high-end systems of an architecture. Let's not squander it on myopic views of datacenter class hardware that don't exist yet leveraging specifications that nobody is implementing in currently available hardware. Insofar as subarches go, let's just define them in RPM like we have for 32-bit x86 and more recently 64-bit x86. If we know what kind of ISA profiles are out there, we should just incorporate them into RPM and set up the compatibility detection logic for them to work. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
