On 4/15/23 19:56, Kevin Fenzi wrote: > On Sat, Apr 15, 2023 at 08:38:47AM -0600, Jeff Law wrote: >> >> >> On 4/15/23 00:10, David Abdurachmanov wrote: >> >> >>> >>> We have to support SCBs as-is. We even have 64-core OoO (and even >>> dual-socket 128-core) systems coming that are still RVA20 (what I call >>> "a large scale SBC trying to be a server"). >> I think elsewhere you suggested treating the profile as the subarch for RPM. >> That may be a viable way to handle the SBC space. >> >> I still worry about supporting multiple profiles and would like to see a >> clear path to deprecating profiles that are out of date. The amount of pain >> I've seen in both the x86 and aarch worlds WRT baselines is something I'm >> keen to avoid repeating. > > Yeah, completely agreed. From an infrastructure standpoint, I would love > to get riscv in fedora as a primary arch, but I don't think it's > practical at all to bring in 3 or 4 or whatever subarches. There's just > no hardware that could actually keep up with mainline fedora currently > and the duplication of effort building 23,000 packages over N slightly > different subarches is not very tenable. > Probably each hardware vendor will need to become more involved in creating an RPM distribution for their use case and providing hardware for test builds. A single monolithic Fedora will not work. Having a subset of base packages would be very helpful. > The rpm subarches might be a useful path, but then determining what you > build for multiple of them and how needs to be addressed. > The great thing about Linux is easy customisability. There may be a few RISC V variants that are widely used, but not clear which at present. The D1 chip is very affordable, and can have much use in education and IoT, though most support at present is available for Debian and OpenWRT. Fedora probably seems to need more work for this. > I think we can point people to arm history and try and get them to not > repeat it (although perhaps it's too late for a lot of it). >>> >>> But Fedora RISCV as-is is not how future Fedora RISCV should be. The >>> future is RVA23 (or beyond) and standard compliance. There will be >>> significant performance differences between profiles for some time. >>> Especially RVA20 -> RVA23. RVA20 (or RVA64GC) is just way too small >>> with lack of modern ISA. We have had a toy for ~10 years now, and now >>> we are moving toward high-performance servers, even HPC, Android (see >>> latest Google announcements), etc. That's not driven by RVA20. That's >>> RVA23 (and beyond) + vendor extensions. > > Completely agree. > Maybe we need a RISC V sig? >>> Yes! Blocked by lack of "hw probe" interface. There will be "hw probe" >>> syscall for RISCV, in v6.4 and v6.5 kernel (I hope). We don't have >>> cpuid instruction, HWCAP is way too small for all the extensions >>> available. >> I'm sure folks will get this sorted out. My only concern with the syscall >> was to make sure the glibc folks were on board with using that to drive >> ifunc selection. It's a fairly different approach than has been taken in >> the past and I want to make sure it's not DOA for glibc. >> >> Once the kernel & glibc teams reach API agreement I think we'll be able to >> make a reasonable query about the system properties in multiple contexts, >> including the installer, rpm, etc. > > That would be great. > >>> Note that toolchains don't accept RISCV Profiles yet, but that has >>> been under discussion for quite some time already. I would assume >>> starting GCC 14 timeframe all of that should work. >> It'll get sorted out. We've got some bigger fish to fry WRT landing V >> support (if you've managed to avoid that mess, consider yourself lucky). >> >> Lots of stuff is backed up behind getting gcc-13 out the door so that gcc-14 >> development can open up. Not sure where profiles will fall into the >> priority list, it's hard to see past the V effort right now. > > Yep. And a lot of it is things that just need to mature and hardware > that needs to exist and code and... ;) But hopefully we will get there. > > kevin > > _______________________________________________ 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
