It seems we are more and more at taking a shot at kernel dev, I mean a full kernel.
What is really annoying with linux (and *BSD), it is their dependence on gcc/clang. It is not C, it is a dialect of C using too many bazillions gcc extensions. It means in the long run, we are hit straight in the face with planned obsolescence from C syntax, as ISO tantrums(c11/c17/c7489374893749387) or some ultra-recent gcc extensions ("sorry, you need THIS extension only available in gcc from 2 weeks ago").
I have been coding assembly lately, and being independent of those compilers gives me an exhilarating feeling of freedom.
Who said 64Bits RISC-V assembly written (with a conservative usage of a preprocessor) linux compatible enough kernel which runs the steam client, dota2/csgo and those horrible "modern" javascripted web browsers (I personnaly use only noscript/basic (x)html browsers)? Would even be fine for a self-hosted mini server (email, personal web/git(mirrors) site, p2p, all ipv6 to avoid that disgusting ipv4 NAT, etc).
To stay real, I would go incrementaly: I would start slowly by moving back some linux code to real C (namely _NOT_ compiling only with gcc/clang, and this will be hard), port some code paths to assembly, probably x86_64 at first then 64bits RISC-V would follow (and why not ARM64).
I am more than fine with linux GPLv2, actually, I would provide the "new" code under affero GPLv3 with a similar linux "normal" program exception (but more accurately defined, to target drivers in userspace and stay explicitely ok with closed source userspace programs using those drivers) _and_ as linux GPLv2(and more based on their author wishes) to be legal with re-used linux code.
So it used to be possible to compile a (lightly patched?) Linux with tcc, which was part of the really cool "live disk that compiles linux and then boots it in a matter of seconds" demo[0]. I think the problem is that kernels (need to!) care about extremely precise implementation details that most programs don't need; things like "this data structure of exactly this many bytes must be placed at this exact memory address with this exact alignment, then we need to set the CPU registers to this exact list without touching the stack, then run this CPU instruction to make the hardware do the action we just staged", and they care about doing so with good performance, and AIUI, spec-based C either can't do all the things that modern OSs want, need you to jump through a lot of unergonomic hoops, or don't get the performance that people want. Hence, compiler extensions to do what the kernel wants to do while minimizing undefined behavior but keeping performance. Honestly, the fact that every major OS (I specifically know about Linux, every BSD, illumos nee Open/Solaris, but I'd be shocked if NT/Darwin were different) needs to extend the compiler is probably a glaring criticism of the C standard.
It means that in the end, maintaining duplicated assembly code paths for different ISAs would have been cheaper and much easier than the absurdely complex linux+gcc(or clang) duo. And I could bet than some code paths could be kept in simple and plain C (compiling with _not_ only gcc/clang) without that much loss of performance.
Erm. So that's a language/compiler issue, nothing to do with the ISA? And I might be on board with embedding assembly, but AFAIK that also requires compiler extensions. And I'm not an expert on compilers or C, but I suspect that still doesn't cover all the uses of compiler extensions.
Since RISC-V should be an international standard for assembly level interoperability, that removes in a reasonable way this "compiler/language" issue ... until no technically very expensive code generators/code preprocessors are used since those would not be that less worse than an optimizing compiler.
Write RISC-V assembly once, run anywhere.
The cherry on top, RISC-V ISAs do not have toxic IP tied to them, like x86_64 or ARM, and that at a worldwide level.
I would be ready to pay the price of losing some speed on C code paths until I can compile them with "toy"/small/alternative compilers which are not gcc/clang, BUT I cannot even do that since linux code is hard dependent on gcc extensions.
>>OpenMandriva Lx is a unique and independent linux distribution, a direct descendant of Mandriva Linux and the first Linux distribution utilise the LLVM compiler
What is really annoying with linux (and *BSD), it is their dependence on gcc/clang. It is not C, it is a dialect of C using too many bazillions gcc extensions. It means in the long run, we are hit straight in the face with planned obsolescence from C syntax, as ISO tantrums(c11/c17/c7489374893749387) or some ultra-recent gcc extensions ("sorry, you need THIS extension only available in gcc from 2 weeks ago").
I have been coding assembly lately, and being independent of those compilers gives me an exhilarating feeling of freedom.
Who said 64Bits RISC-V assembly written (with a conservative usage of a preprocessor) linux compatible enough kernel which runs the steam client, dota2/csgo and those horrible "modern" javascripted web browsers (I personnaly use only noscript/basic (x)html browsers)? Would even be fine for a self-hosted mini server (email, personal web/git(mirrors) site, p2p, all ipv6 to avoid that disgusting ipv4 NAT, etc).
To stay real, I would go incrementaly: I would start slowly by moving back some linux code to real C (namely _NOT_ compiling only with gcc/clang, and this will be hard), port some code paths to assembly, probably x86_64 at first then 64bits RISC-V would follow (and why not ARM64).
I am more than fine with linux GPLv2, actually, I would provide the "new" code under affero GPLv3 with a similar linux "normal" program exception (but more accurately defined, to target drivers in userspace and stay explicitely ok with closed source userspace programs using those drivers) _and_ as linux GPLv2(and more based on their author wishes) to be legal with re-used linux code.