News: 0001581306

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

RISC-V With Linux 6.18 Brings Support For MIPS Vendor Extensions

([RISC-V] 3 Hours Ago Linux 6.18 + RISC-V)


Back during the Linux 6.17 merge window [1]the RISC-V changes were rejected as "garbage" for being submitted too late in the merge window and with some code choices that upset Linus Torvalds. With lessons learned, the RISC-V changes for Linux 6.18 were submitted today during the first official day of this new kernel cycle.

The first batch of RISC-V feature updates were submitted for Linux 6.18. Standing out is support for detecting and utilizing MIPS vendor extensions for RISC-V. Not to be confused with the defunct MIPS64 CPU ISA but rather MIPS' additions for the RISC-V world now that MIPS Tech is focused on RISC-V processors.

Initially this MIPS extension work for RISC-V is focused around MIPS P8700 specific work and making use of their new "PAUSE" implementation.

"- Replacement of __ASSEMBLY__ with __ASSEMBLER__ in header files (other architectures have already merged this type of cleanup)

- The introduction of ioremap_wc() for RISC-V

- Cleanup of the RISC-V kprobes code to use mostly-extant macros rather than open code

- A RISC-V kprobes unit test

- An architecture-specific endianness swap macro set implementation, leveraging some dedicated RISC-V instructions for this purpose if they are available

- The ability to identity and communicate to userspace the presence of a MIPS P8700-specific ISA extension, and to leverage its MIPS-specific PAUSE implementation in cpu_relax()

- Several other miscellaneous cleanups"

More details on these RISC-V changes for Linux 6.18 via [2]this pull request .



[1] https://www.phoronix.com/news/Linux-6.17-RISC-V-Rejected

[2] https://lore.kernel.org/lkml/2c804359-3d43-0fba-7173-a87f9aec4bd2@kernel.org/



phoronix

... and for absolute majority of programmers additional shared objects mean
additional fsckup sources. I don't trust them to write correct async code.
OK, so I don't trust the majority of programmers to find their dicks if
you take their Visual Masturbation Aid++ away, but that's another story -
I'm talking about otherwise clued people, not burger-flippers armed with
Foo For Complete Dummies in 24 Hours.

- Al Viro about multi-threading on linux-kernel