Description
There are a plethora of Linux kernel features that have been added to RISC-V, where many of them resulted from direct discussions during last year's Linux Plumbers RISC-V microconference, and many more are waiting to be reviewed in the mailing list.
Topics planned to be discussed this year include:
RISC-V Platform Specification
Making RISC-V Embedded Base Boot Requirement (EBBR) compatible
RISC-V 32-bit glibc port
RISC-V hypervisor extension
An introduction of vector ISA support in RISCV Linux
RISC-V Linux Tracing Status
When RISC-V grows up, it wants to be a wildly successful
computing platform. Being an ISA is fun but being the world's
fastest supercomputer would be really cool.
So how do we get there? By being dead boring. If I have an operating
system to install on a platform built around the RISC-V ISA, the install
MUST work out of the box -- no mucking about with strange boot loaders,
or...
There are ongoing efforts to add UEFI support for RISC-V Linux kernel. As a result, RISC-V can be fully EBBR compatible. We will discuss the current progress and what's the best approach to make that happen.
The hypervisor extension v0.5 is already available in the latest Qemu and v0.6.1 patches are already in the mailing list. The kvm patches has been on the mailing list and waiting to be merged. We will discuss the ongoing designs for nested hypervisor implementation.
We will talk about the implementation of vector support in Linux kernel, how user space can get its layout or size and the future work for Linux kernel and glibc.
The Linux RISC-V Kernel has adopted a policy to accept patches only for frozen/ratified RISC-V specs. This was done to align with RISC-V spec development process of the RISC-V Foundation and avoid maintenance burden. Considering the time taken by RISC-V spec development process, is there a better policy which Linux RISC-V Kernel can adopt ??
Projects such as QEMU RISC-V and OpenSBI have...
This will include details about the 64- bit time_t problem and how RV32 is going to be the first 32-bit architecture with a 64-bit time_t. What still needs to be done for 32-bit support? How do we get this merged? We will also like to discuss the plan to test and maintain it once it is merged.