— START ADMIN EDIT—
This was split off from the riscv64 port status topic at X512’s request. Feel free to pick up any discussion here about how the project accepts patches until an admin gets upset enough to lock the topic lol — END ADMIN EDIT—
I really do not see what the fuss is about… x512 is creating a port of Haiku for a totally new platform and he’s being dissed over his choice (or his own creation) of bootloader for it? How do developers and users get to squabbling like this? He says he’s willing to maintain it until he’s no longer interested in Haiku, so why is it such a hated thing? Everyone is basically “doing their own thing” concerning Haiku anyways, so how is this any different? He’s just doing what everyone else is doing. But his way is wrong and everyone else’s is right? He contributes what he likes, when he likes, and how he likes. But that’s ok for others, but not for him? Why?
Maybe I’m missing something, but I’ve got X512’s back on this matter, so far as I’ve read and watched.
Not that much honestly, Just an issue blown way out of proportion and some misunderstandings ontop of it.
Just dropping this matter and moving on would be best IMO.
I think you are overdramatizing here, you did not comment on the ticket to adress the arguments, outline alternatives, or try to reach a compromise (like the one proposed in the ticket).
Rejection would have been simply reverting the already merged code, which has not happened.
It does not, It presents arguments, and a thesis based on that.
The ticket uses the wording “should probably” to indicate that it is still an open issue.
Why not address the arguments in the ticket? If you present your counter-arguments a synthesis can be reached. This is how Haiku development generally works, to try and resolve technical disagreements via discussions.
Dragging this out into the forum serves no purpose IMO, it only seems to add more agitation for no real gain.
I already said arguments many times in many places and all related developers likely already clearly understand them (and waddlesplash still disagree with them). I see no meaning in repeating. Nothing new from me.
There are no discussion, there is one person (waddlesplash) forcing his destructive opinion. Nobody else from Haiku developers rejecting haiku_loader.riscv.
Waddlesplash isn’t forcing anything, and he is allowed to have opinions. From an outsider perspective (of this argument) he has been very polite and layed out his arguments quite clearly, the only thing I heard from you was that you claimed that this is ideological, and not technical, and threatening to not cooperate with upstreaming any further unless Waddlesplash is forbidden from raising objections (As in promise to not put -2 on the review), which I think is a quite unreasonable thing to ask.
I would be very happy to see a fork of haiku, optimized just for risc-v and implementing your own ideas related to vulkan. The people around haiku are very conservative and are very adverse when somebody wants something more modern.
Think about holding your code on a private git server (I do the same with my code, I use for the moment google cloud as a backup, but soon I will have my own server room). The costs for a google cloud server is less than 10 euro a month.
I am pretty sure it will help you a lot if you are in control of the development. Arguing, and explaining, and fighting against people who don´t have a deep understanding will cost you a lot of time and energy. You need just one risc-v hardware/pc to support and show that it can have good performance.
You will find easily supporters and donations because your work is amazing.
If you start your own project, I would be very happy to be one of the supporters, please let me know per email since I might leave even the haiku forums.
My Email: cipri@riscv64.com
As I said above, I created the ticket because kallisti5 and others seemed to agree with the reasoning behind it.
I have said many times now that if the other Haiku developers think I am wrong one way or another, that I will go along with that and rescind my objections.
I am trying to still treat this as a technical disagreement. I am not really happy with how it is being made into an ideological one.
I’m not sure where you are getting the idea that we are adverse to things that are “more modern.” Certainly we are slow to adopt them for a number of reasons, mostly due to lack of time, but Haiku has all sorts of modern conventions, paradigms, and technologies in use and I’m sure we will continue to adopt more.
What we are adverse to is change for change’s sake. Plenty of other OSes change their design, internals, add features with questionable uses, or any number of other things. We try very hard, partially because we know how much time we do or do not have, to make every decision make sense with the overall vision, and leave experimentation separate from the main project itself; whether that means it is in another repository entirely, or contained in some obscure subdirectory.
The RISC-V port is on its way to being a first-class citizen of Haiku, not some crazy experiment, and so as such we are trying to keep it up to the same stringent standards we do everything else with, and not use it as a playground for experimentation. That is ultimately the source of my criticisms of this one component, as well as some other matters relating to the port.
(Also, anyone who wanted to take Haiku closed-source would have to do a careful audit and rip out a lot of code. While Haiku code is largely MIT, there is a good chunk of third party code in the repository, including a large amount used in the core OS, which is various forms of GPLed.)
I have some long term plans to move to Clang and strip glibc and libgcc_s code, replacing it with LLVM and Musl parts. FreeBSD already have binary compatible libgcc_s.so based on LLVM libunwind. GCC produce a lot of miscompilations (example) for code that work perfectly fine with Clang.
I see no reasons to follow Linux dictated “standards” (u-boot). Haiku is stand alone and independent from Linux. Original Be developers also developed their own boot loader for BeBox.
u-boot is painful and hard to work with. For example I need to type “pci enum ; usb start ; run bootcmd_usb0” every time I boot on real hardware. Otherwise haiku_loader.efi will not see any bootable discs. I am waiting functional EDK2 RISC-V port that provides more desktop like experience with boot menu and without ugly scripts.
It is even not possible to turn off stupid countdown timer without recompilation. There are no “saveenv” command.
u-boot also don’t want to boot from disk if it have no partition table.
glibc is not the only relevant code, but yes, it is a larger part. Getting off it would indeed be good. I already ripped out glibc libm and replaced it with musl’s some time ago. I started looking at libio, but there were compatibility differences there, and I never got back to it.
SBI support is implemented in kernel and used for EFI boot. haiku_loader.riscv currently provides its own machine mode interface called MSyscall. There are currently only one syscall needed by kernel kMSyscallSetTimer. Adding another syscall will be probably needed for SMP and sending inter-CPU interrupts (ICI). So just only two syscalls instead of a lot of SBI syscalls. MSyscall implementation is simple and SBI is just not needed. It is also easier to debug haiku_loader.riscv instead of OpenSBI in case of problems.
I think the ticket can just be considered as something to consider later when things are further along in the port. I don’t think you should take it too personally. I will admit I do not yet understand some of the technical details so I won’t offer my ignorant opinion on the matter. I definitely see your perspective on offering a simpler bootloader interface and it reminds me of what ChromeOS does with CoreBoot and it makes the booting experience much better there. Of course we are not Google with the same resources, so it remains to be seen if maintaining our own bootloader becomes a burden. I think the agreement is that it is fine for now, so let’s move on?
I will say I think the Haiku community has a good track record of working though discussions and keeping consensus and I think that has helped such a small community make pretty good progress on the OS. I know you have worked really hard on the port and any criticisms can seem personal but please don’t take them that way. We have all worked hard on code to have someone come along and say it needs more work. That can be frustrating but usually it ends up improving things.
I really disagree with this, and I don’t know where you get this info from. It seems that you just make things up as you go.
If what you say is true, we should remove opensolaris, m68k and other experiments from our tree directly. I really wish you stop trying to dictate what others should do.
I am not sure where you are getting this idea that I am somehow trying to order people around. I have technical or cultural opinions, and I voice them and spend time arguing for them. I don’t have authority to give orders, and so I don’t.
Those other architecture ports in the tree may be to obscure or now little used architectures, and they may well be incomplete, and so in a sense “experimental”, but in the broader sense they aren’t; the code in them is generally right on par with the rest of Haiku, and they too might become first class citizens if they are ever completed. PulkoMandy’s SPARC work in particular has been especially solid and has lead to a lot of important cleanups in other parts of the codebase.