| Child pages (Children Display) |
|---|
...
- Issues common to multiple Linux distros (e.g. bugs/features in common packages)
- Enabling a specific Linux distro, provided the Linux distro has a champion/vendor.
- The champion identifies the directions/projects
- The WG works to prioritize, unravel dependencies on other WGs or file projects in other WGs
Meetings
The Distro Integration working group meets bi-weekly with following dates in 2024:
- 2024-01-02
- 2024-01-16
- 2024-01-30
- 2024-02-06
- ...
The group has agreed to make it's meetings open to members the guest link is available here:
<TO BE PROVIDED BY RISE ADMIN STAFF>
Resources
...
Brian Harrington shared a number of concerns with the mailing list, related to both direct concerns held by distros as well as desired output from distros:
Mailing List Updates:
Concerns from distros:
1) How will we handle packaging of libraries and binaries? - We should engage in a public, community discussion of packaging concerns. Things like 'What are the "trade-offs" of "fat" multi-arch binaries?', 'How do we avoid having to maintain more than a single "boot image" for RISC-V?', etc.
2) What does the system provisioning process look like? - Deployment patterns over the years have oscillated back and forth between installation and image based deployments. An installation workflow allows for more checking and recovery while an image based deployment can be faster. Do we need more ratification around how net booting is handled for example?
3) Who "owns" the ELF specification? As far as I'm aware it's still (at least on paper) the remnants of the Santa Cruz Organization (SCO). I've talked about this with Uli. Can anyone else disabuse me of this notion? Should this be under the purview of RISE?
4) Are there common patterns we can align on around workflows for kernel updates (for example workflows like KSplice) which may be used due the intersection of HSM kernel patches and better HART support in the firmware?
What third-parties want distros to contribute:
1) Provide public test harnesses for performing validation. i.e. "Can Red Hat provide and maintain a public provisioning manifest where Rivos/Si-Five/Redbeard's Fictitious Server Company can pull these assets and perform full system installs as a part of internal continuous integration testing?")
2) An agreed upon/trusted "SDK" for building downstream projects. This could look like a compiler toolchain hosted by RISE. Personally, I've gone back and forth mentally on this and just keep thinking about Ken Thompson's paper "Reflections on Trusting Trust".
Distro Updates:
Fedora (via David Abdurachmanov) currently has over 80%+ of package builds with AMD64/x86_64. This currently includes Kernel (6.26), GCC (13.1.1), LLVM (16.0.5), CMake (3.26.4), nasm (2.16.1),
...
Heinrich Schuchardt (Canonical) brought up distro support for RISC-V extensions being an important problem to be solved. On AArch64 "ifuncs" were used, for example, to select the right atomics implementation (e.g. to support ARMv8.1 LSE). I found https://lpc.events/event/11/contributions/1103/attachments/832/1576/Puzzle%20for%20RISC-V%20ifunc.pdf, but unsure how old this is.
Kumar had previously sent a list of possible projects, and this included something named "Standard RISC-V framework for all distros" - including boot (DT/ACPI), Interrupt controller/IOMMU (AIA, IOMMU) support and such. Now obviously this is kernel work, but maybe this means the "distro integration" projects are more about identifying and tracking all the meaningful dependencies between kernel / libs / apps that may exist to deliver a specific feature/experience?