[deleted]
Debian riscv64
61–70 of 155 posts
Re: Debian riscv64
#62I wanted to check first, and I wasn't saddened when I found netbsd was also available for riscv64. That being said, having a full debian suite to nicely land on is what will gain it adoption. It's a chicken and egg problem where one side is vigorously designing and publishing a hardware spec in search of an operating system and at the same time an entire eco-system of open source development is in search of open hard…
Only benefit is companies not having to pay ARM. The architecture NEVER WAS A PROBLEM for open, it was always the binary blobs required to run IP blocks put on the die with the cores that stopped people from using them.
ISA is the easy part. Even if you need to RE it, you only need to do it once.
Now hopefully with RISC V companies will be even more inclined to just upstream their drivers from the start (and not do the abominations that happen way too often on ARM side), but the ISA never was a problem for that.
Re: Debian riscv64
#63Earlier quoted context omitted.
Well-written applications will just work. Badly-written applications may require patches or be impractical to build at all, and some system software may not make sense on the architecture at all. There's a whole lot of build infrastructure for Debian; by default the package maintainer doesn't need to do anything specific, building for all architectures will happen by default.
What kind of assumptions would badly-written applications make to make themselves impractical to cross-build?
Assembler optimizations without fallback to pure C for other architectures for example.
Re: Debian riscv64
#64Earlier quoted context omitted.
Would anything prevent compilers from approaching it like SSE on Intel? Check for feature presence and enable the appropriate path (if using compiler-generated code).
> Check for feature presence That is the hard part. On Intel you can use CPUID, but it is ARM policy to not expose such instructions. You can read /proc/cpuinfo, but that is Linux-specific. Edit: there is a reason for ARM policy: CPUID is a well known virtualization hazard. In fact, KVM immediately traps if you execute CPUID on guest. ARM made a good decision here. Still, it means things can't work exactly like it wo…
The Arm Linux kernel allows you to use some of the "read ID register" instructions from userspace, because it traps them in the kernel and emulates them to present you with a slightly sanitized view of the available hardware: https://www.kernel.org/doc/html/v5.8/arm64/cpu-feature-regis...
You can also look at the hwcaps (available in the ELF aux vector) -- this is the older mechanism.
It's true that there's no cross-OS mechanism to do this, but that's life -- often the OS wants to get in anyway to sanitize the answers (eg so it can tell you "feature X is not present" when it knows about a hardware erratum or the OS was built without feature-X support).
Re: Debian riscv64
#65I wanted to check first, and I wasn't saddened when I found netbsd was also available for riscv64. That being said, having a full debian suite to nicely land on is what will gain it adoption. It's a chicken and egg problem where one side is vigorously designing and publishing a hardware spec in search of an operating system and at the same time an entire eco-system of open source development is in search of open hard…
No snarkiness intended, but I just read your post for the 3rd time and although I understand each sentence individually, I'm still not sure what point you're trying to make.
Surely that was generated by an LLM?
Artificial indeed.
Re: Debian riscv64
#66Earlier quoted context omitted.
> Check for feature presence That is the hard part. On Intel you can use CPUID, but it is ARM policy to not expose such instructions. You can read /proc/cpuinfo, but that is Linux-specific. Edit: there is a reason for ARM policy: CPUID is a well known virtualization hazard. In fact, KVM immediately traps if you execute CPUID on guest. ARM made a good decision here. Still, it means things can't work exactly like it wo…
But specific instructions should be testable anyway, right? Try to execute with an exception handler and you'll know.
On Arm this is generally a bad idea -- there are, or were, some corner cases where the kernel can know that an extension shouldn't be used, but it doesn't have a mechanism for "make the instructions UNDEF". The example I know about is ancient history now -- on the Cortex-A8 I think you could build a kernel without Neon support or perhaps the kernel might find there was a Neon-related erratum, but there was no way to disable Neon to force the UNDEFs.
The recommended approach is to use HWCAPs, or else to use the kernel's "emulated ID register accesses" functionality.
Re: Debian riscv64
#67a true milestone! hope it is also the beginning of the end - ISA shouldn't be some tightly controlled assets managed by some lawyers and CXOs, companies shouldn't be sued for just trying to invest into certain ecosystems.
why?
As open source options mature & become more plentiful, it simply becomes more 'painful' for companies to ignore / go a closed sourced route.
Closed source = extra cost, licensing red tape & so on. However small, it's a bother.
Need an OS? Grab open source one. Want that + 'secret sauce'? Grab BSD flavour OS & add your secret sauce. Want OS with custom user interface? Grab open source OS & add custom UI shell.
Going closed source for anything where open source does the job, just means extra development effort, or paying 3rd party $$ while (often) not necessary. And eg. $0.05 royalties / device matters when it's a part with $3 production cost.
On the hardware side this is a much slower moving train. But same principle.
Re: Debian riscv64
#68Earlier quoted context omitted.
Well-written applications will just work. Badly-written applications may require patches or be impractical to build at all, and some system software may not make sense on the architecture at all. There's a whole lot of build infrastructure for Debian; by default the package maintainer doesn't need to do anything specific, building for all architectures will happen by default.
What kind of assumptions would badly-written applications make to make themselves impractical to cross-build?
All Debian packages are built natively. There is no cross build going on here.
Re: Debian riscv64
#69Earlier quoted context omitted.
No snarkiness intended, but I just read your post for the 3rd time and although I understand each sentence individually, I'm still not sure what point you're trying to make.
It's an amazing accomplishment that we'll see the benefits of for centuries. The culmination of a free operating system on free hardware that is.
Thanks for the summary, the original text makes more sense with that as context.
Re: Debian riscv64
#70Earlier quoted context omitted.
I’ve noticed a lot of projects use riscv64 as shorthand for the rv64gc ISA, especially when it’s understood that there is an MMU, maybe an FPU, privilege levels, and any other extensions that a modern OS requires. Anyway, I did find this on the Debian website[1]. So it seems they mean rv64gc. [1] https://wiki.debian.org/RISC-V#Hardware_baseline_and_ABI_cho...
Presumably Android will also chose a base minimum ISA spec for riscv software at some point. It would be tidy if they match the regular linux ecosystem
It has not been decided. There was a talk about the details just 2 weeks ago on the RISC-V International Youtube channel. Very interesting and recommended.