On Sat, Apr 15, 2023 at 5:01 AM 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. Remember that profiles are important for binaries that we ship, but the top level specification for the actual hardware systems will be RISCV Platforms. If you want to run Linux (especially enterprise level) you will implement that. Distributions will target a specific profile to support. > > > > > 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. They are, because that's what folks can afford for development, for their CI/CD pipelines, etc. I have seen the same situation in early ARMv8/AArch64 life. It was crazy expensive and hard to get systems. Even SiFive HiFive Unmatched is expensive for developers to invest in. I have heard that directly from the developers. > 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. It does. We (as a community and individuals) have to push for standards compliant SBCs and they should work the same way as a rack mount system. I wouldn't mind for CentOS Stream RISCV (and other rebuilds) not to support anything lower than RVA23 and fully standard compliant (once that happens). That's sane, but Fedora RISCV is in a different place. > > 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. Disclosure time. For folks that don't know me: - I have been building Fedora RISCV with Richard since ~2016. - I lead the current Fedora RISCV (fedora.riscv.rocks) efforts. - I worked for SiFive, and worked on some SBCs that you might know. - Today I work for Rivos (another RISCV startup). - Before I used to work at CERN and especially on ARMv8 64-bit/AArch64 craziness since early days. > > > > > > Still, it would be neat if there was a good technical solution for > > subarchitecture diversity because there will be more of it in the > > future. Jim Keller, the prolific CPU designer who worked on DEC Alpha, > > AMD K7 and Zen, Intel, Tesla, and Apple, has an interesting talk where > > he justifies going to RISC-V architecture because it is so much easier > > to extend it for high performance on specific tasks: > The fragmentation will kill RISC-V from a distro standpoint if it's not > brought under control -- and I had that position well before I joined > the RISC-V world. Profiles are a step, but by no means a complete > solution. Distros are terrible at supporting ISA customizations. Fragmentation issue on RISC-V is a bigger problem than in ARM land. Profiles are trying to help here, but true, it's not a solution on its own. Cheers, david > > heff > _______________________________________________ > 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 _______________________________________________ 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
