skift VS haiku

Because it's traditional to use C for freestanding stuff but C++ is as capable as C to be use for freestanding code. For example here is a bootloader written in hight level C++ https://github.com/skiftOS/skift/blob/main/src/loader/loader.cpp

> I'm not sure why one would write a new OS in C++ in 2021/2022

numbers of hobby C++ OS started from scratch which went from zero to GUI in a couple years: at least 4 - SerenityOS, this, https://github.com/skiftOS/skift, https://github.com/Supercip971/WingOS

how many in other languages ?

https://skiftos.org https://brutal.smnx.sh https://serenityos.org

Here is the CI workflow I used https://github.com/skiftOS/skift/tree/main/.github/workflows

What touches me the most is how much I like the GUI applications look like [0][1]. As a person, who use GNOME Shell DE I really miss to see the titlebars condensed with the menu just like VSCode does. It was what I liked in the very last Unity DE and I happy to see this once again. I am also amazed how simple the TextEditor is [2][3] and how handy looks your libwidget components. Congratulations!

[0]: https://www.reddit.com/r/osdev/comments/ky7igd/my_handmade_w...

[1]: https://www.youtube.com/watch?v=Za0oHBFr9zo

[2]: https://github.com/skiftOS/skift/blob/main/libraries/libwidg...

[3]: https://github.com/skiftOS/skift/blob/main/libraries/libwidg...

[4]: https://github.com/skiftOS/skift/tree/main/libraries/libwidg...

Haiku uses the System V ABI (mostly.) So, we're doing the same things Linux and the BSDs are here, simply by using GCC or Clang without any special tuning here.

> I reckon that before trying to claim you've innovated here it might be a good sense check to compare baseline.

The baseline is "what are other operating systems' kernel- and userland-level condition variables APIs?" And none of the ones I looked at had anything like what Haiku has here, they all have something which is the more classical "lock-switched condvars" just like POSIX has.

The API itself does not depend on what memory ordering semantics are any more than a "mutex_lock()" API does. The implementation will be somewhat contingent on it, of course, but those are two separate matters.

> What exactly are the Haiku atomic operations, in terms of the C++ 11 Memory Model?

The atomic_() functions are (on most architectures, x86 included) implemented using GCC/Clang's __atomic_* functions, with various __ATOMIC_* orderings chosen as appropriate. You can see them defined in the system header here: https://github.com/haiku/haiku/blob/master/headers/os/suppor...

> because you're innovating before 2011, you're inventing the model

No, not really? GCC has had atomic builtins since at least 4.1.0 in 2006. The documentation (https://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Atomic-Builtins...) says: "In most cases, these builtins are considered a full barrier. That is, no memory operand will be moved across the operation, either forward or backward." -- which is basically equivalent to today's __ATOMIC_SEQ_CST.

> so Haiku is off in the jungle on its own and everybody else has a map now, figure out where you are on that map first.

We already did that years ago. The atomic_() functions linked above in SupportDefs.h have been implemented using the C++11-standard GCC builtins since 2014, and the older __sync_ builtins for years before that.

Anyway, the algorithm described in this article, even if Haiku's atomic functions were not 1:1 with C++11-standard definitions (which they are, as noted above), is clearly portable to other OS kernels. So I am not sure what basis your comment has, regardless.

I'm currently trying to build Haiku from source (following https://github.com/haiku/haiku/blob/master/ReadMe.Compiling.md), but I'm getting errors while building with "jam -q -j12 @nightly-anyboot".

Something like this? https://github.com/haiku/haiku/tree/master/src/add-ons/accelerants/radeon