Haiku to NetBSD port coming to life

Development OS
1

As I announced on the respective Mailing Lists (and the topic found its way into this forum as well), I have been working on Haiku compatibility for NetBSD.

This is done mostly on the libroot layer, where missing functions were implemented backed by NetBSD APIs and 3 kernel drivers for IPC. Also the kits and appserver have received some patches. Many of them come from Cosmoe, which is luckily under active development again. Without it, this would not have been possible.

The port reached a state where something visible can be seen, so I have some impressions. The appserver uses the SDL driver from Cosmoe to render to a window inside an X11 session.

This was shortly after libbe, appserver and 3 - 4 simple apps were compiled. Some last fixes were needed in the application kit to make the apps connect to the appserver, and to the area kernel driver. Smearing next to the app windows can be seen because the appserver doesn´t seem to redraw the background if “nothing” is behind windows.

1
11864Ă—944 194 KB

Libtracker and Tracker itself were compiled, as well as some more apps. Tracker ran but did not do much besides drawing the background, which was however utterly needed. Resource embedding was completely missing, that is why the Clock looks weird and didn´t work.

2
21890Ă—953 223 KB

It took some time to get the Resource tools built and integrated. Loading resources didn´t work at first and it was pretty hard to find out that the issue was caused by a misunderstanding between Haiku’s ByteOrder.h and NetBSD’s endian.h on the endianess of the host CPU.

3
31895Ă—973 195 KB

Next registrar and Deskbar were built. Registrar was needed to get Pulse messages working, which some apps need. It was neat to see that running apps showed up in Deskbar. However, Pulse messages did not work from the start and unveiled a bug in the system_time() implementation and the semaphore kernel driver handling absolute timeouts (which was pretty much the only thing not really tested beforehand).

4
41884Ă—975 171 KB

Several fixes later, most of all in the Storage Kit, Tracker does a little bit more and shows the Desktop menu. Resource loading form libtracker was added, but I doubt it can load all resources at this point. Also Deskbar has received its resources and displays the menu icon. I also found a little Terminal app in the Cosmoe sources, tweaked it a bit and got it running.

5
51875Ă—930 224 KB

31 Likes
2

Amazing stuff! Keep us updated.

3

This is absolutely remarkable! How are you handling BFS attributes? Are they being passed through to UFS xattrs?

4

In theory yes, I have imported Cosmoe code that uses functions from xattr.h (IIUC that´s not NetBSD’s native API, but it supports xattr.h). However, the filesystem is not mountend with extended attributes turned on and the wrapper has not been testet at all. It didn´t seem to be necessary to get to this state… :slight_smile:

5

Nice work. Are you planning to break out of the need for an X11 session?

6

Not in the near future. The current setup is well suited for development. Maybe the remote (HTML5) appserver will be an option anytime soon. To run appserver locally without X11, one option could be to convert the SDL2 backend to SDL1, since that supports NetBSD wscons graphics. A better solution would be a native driver (and working input_server), but that won´t be written by me, since I am not familiar with graphics processing.

7

Since Haiku works with framebuffers for UEFI and Vesa a variation of that driver should be doable without knowing much.

1 Like
8

This looks amazing!

Is this a ABI-compatible port like HyClone, or more of a Be API layer on top of NetBSD?

2 Likes
9

The latter… the Kits are compiled and linked against NetBSD’s libc and a custom version of libroot.

Side note: The NetBSD kernel is also well suited for ABI emulation of any kind, since every ABI is an emulation, also its “native” one :slight_smile:

2 Likes
10

I see, that approach may be a bit more stable as Haiku doesn’t have a stable kernel interface. However, integration with HaikuPorts may get tricky.

I know, I’ve looked at NetBSD’s Linux emulation driver once, that’s why I asked :slight_smile:

11

May I ask, why to port the Haiku desktop to a kernel which is not as fast as Haiku kernel? At least this is what I think. Why not spend time on working on Haiku directly?

Thanks.

12

Since I recognize you from the Amiga community, this would be like the way that hosted AROS was used to bootstrap unhosted in its early days. Once the bugs are worked out, the duplicated efforts will have paid for themselves as a diagnostic tool and a way to ferret out bugs.

13

But Haiku is already running unhosted :slight_smile:

This is just someone wanting to mix and match projects to see what would happen. It allows to use Haiku apps (after recompiling) on many machines not supported by Haiku. It will likely remain just a weird experiment.

1 Like
14

Never tried the hosted AROS. I think I prefer the baremetal stuff :slight_smile:

Thanks for the details.

@PulkoMandy
Not just an experiment. Someone already did a fork: GitHub - VitruvianOS/Vitruvian: Vitruvian is the human-centric Operating System. · GitHub

15

Yes, there is Vitruvian, there is Cosmoe, there is the NetBSD one in this topic based on Cosmoe, and much earlier there was also BlueEyedOS.

Just many different ways to keep the BeOS legacy alive, depending on which parts you consider relevant (the binary compatibility with exisitng apps? The simplicity of the software architecture? The idea of starting fresh and not trying to base the work on existing systems? The look and feel? The API?).

Haiku is/was probably the craziest of all these projects, trying to tick all the boxes. But that also makes it the most exciting one for developers at least in the early steps. Now that it is a more mature system, catering to actual users, there is less room for this early excitement, it’s a bit more serious, trying to keep things stable, managing beta branches and nightlies, etc. That’s what I mean by “weird experiments”: I don’t expect these projects to grow a big userbase of their own, unless they find some kind of niche to work off of. For example, Cosmoe could be a way to bring Haiku apps to existing Linux systems, for me that may be useful in some cases and encourages me to write Haiku apps, knowing that I can share them with my friends who run Linux. I don’t know if Vitruvian OS has remained compatible with Haiku over the years, knowing the original developer I would guess that he modernized a lot of things and compatibility is not ensured?

But maybe it’s just developers trying interesting things to see if it would work. I hope we can find ways to work together and not compete against each other (it has not always been easy). But in general I’m happy to see people bringing things in new directions :slight_smile:

6 Likes
16

Comparing the number of drivers, I’d say that isn’t a full win. The reason AROS ran hosted first was to postpone the need to write a ton of drivers.