Re: First bits of a Haiku compatibility layer

[waddlesplash <waddlesplash%gmail.com@localhost>]

Greetings,

Haiku developer here.

It's neat to see the BSDs looking at whether they can borrow anything
from us, when we've gained much by borrowing from the BSDs over the
years (from FreeBSD and OpenBSD for WiFi drivers, and NetBSD for our
DNS resolver.)

However, there are a few misconceptions and some potential hurdles I
figured I might point out.

On Mon, 27 Nov 2023 14:38:13 +0100, Stephan wrote:
> What makes it so special is that it is extremely integrated

A significant amount of that integration is not just between the
various parts of the GUI and "desktop environment", though, but
between the userland and the kernel; not just in things like the
native IPC mechanisms, but also in things like the file manager,
network manager, partition editor, Terminal, etc. Porting just the
Application and Interface Kits to other platforms won't be too hard
(and has indeed been done before, as you note); porting the whole
desktop environment in a usable way is another matter.

> It has a zero-latency, pixel-perfect looking GUI

Well, I'd like for both of those to be true, but of course they're
not! Certainly Haiku has a lot lower latency than a standard Linux or
BSD GUI setup, but it's far from zero.

More to the point, the lower latency is in large part due to the input
handling setup. That's a pretty good example of the system's overall
tight coupling: the input_server talks directly to the various kernel
drivers (PS/2, USB HID, etc., all of which are Haiku-native and
implement Haiku-specific interfaces) and then hands off processed
input to the app_server, which distributes it to application(s)
depending on what has focus.

Some of the snappiness is due to architectural choices that will
follow the Interface Kit wherever it goes (e.g. the
every-window-is-a-thread paradigm), but some of it will either be lost
or impaired by the usual ways the stack has previously been ported
elsewhere (e.g. if you run the Interface Kit as "just another toolkit"
on top of X11/Wayland, or even run app_server as a client server like
XWayland does on top of Wayland.)

If you want to run app_server as the actual display server + window
manager directly working with the system framebuffer, modesetting,
etc. that may retain more; but will also require a lot more work.

> That is why I always found it interesting to rebase it on
> a mature unixish operating system, especially NetBSD.
> While the Be engineers may have incorporated some concepts of Unix
> into their OS, it is not so much a Unix or POSIX system.

I know this point has been debated, but at least I am firmly in the
camp that Haiku itself *is* a "unixish" operating system (and so was
BeOS, to a lesser extent.) Both BeOS and Haiku use the fork/exec-based
process model (though fork() in a GUI application indeed doesn't make
much sense, so there were ways of spawning processes without fork/exec
even before posix_spawn came along.) BeOS lacked mmap, pthreads, and
other such "UNIXy" staples, but it had others like "unistd.h" and the
like.

Haiku, meanwhile, is "natively POSIX" in a pretty serious way. Yes,
there's still a distinction between the Haiku-native threads API and
then pthreads, but that's a userspace-only distinction and more an
implementation detail of the libroot than anything else (the only
important difference is having a pthread structure in a TLS slot,
AFAIK.) Meanwhile POSIX mmap() on Haiku and then the Be/Haiku "areas"
API are just two ways to interact with the same thing (one can call
"delete_area" on a mmap'ed region, or "munmap" on a create_area'd
region, and they'll both work, because to the kernel it's all the same
thing in the end.)

Likewise, the networking layer, file permissions, and so much more is
all pretty POSIXy, and has been for a long time. The number of
non-implemented POSIX APIs is pretty small (I'm not sure how many
there even are; probably they're mostly obscure or optional things
that aren't too important, seeing as we've ported some pretty large
applications like QtWebEngine/Chromium.)

> For example, it has its own error codes

Doesn't everyone? I'd be surprised if there was any OS that really had
no more errors besides the ones specified in POSIX.

The real oddity is that Be/Haiku errors are always negative. You'll
never see e.g. "-EINVAL" on Haiku, because EINVAL is itself a negative
number. That feature is relied upon pretty heavily throughout the API,
and it's one of the reasons why no Haiku-native API ever needs errno,
because it'll just return its error codes directly (for example,
create_area() either returns an area_id > 0 on success, or an error
code < 0 on failure.)

Replicating that will be important, or else there's a lot of code
stashed in hard-to-find places that will subtly misbehave...

> IPC

The main IPC mechanism (ports) is more than a little analogous to
AF_UNIX SOCK_DGRAM, and while it's not 1:1 (it's mostly
"connectionless", for instance), you could probably manage to
implement it on top of that (plus a few extensions) if you needed or
wanted to (though it may not be the most efficient.)

> data types and generic lower-level C functions

I think this is actually the bit that will give you the most trouble
to reimplement, not IPC or anything like that.

BeOS and Haiku make serious use of extended filesystem attributes, to
the point where the OS will not function properly without them (it may
not even boot, depending.) Specifically these attributes need to be
*typed* (they aren't always strings; a 4-byte type code is stored
along with the attribute), they need to be of arbitrary lengths (the
total size of attributes on some files will easily reach a few KB; one
cannot actually build Haiku on e.g. ext4 using native ext4 extended
attributes because of this), and they need to be easily enumerable
(note the functions `fs_open_attr_dir` and friends; these allow for
enumerating attributes on a file like `readdir` for a directory).

That's just the basics; there are some other features of attributes
that will be even trickier to implement (for example: it's possible on
Haiku for symlinks to have attributes, separate from the file they
refer to.) I don't think any other filesystem save BeFS even supports
all these features natively (though some you could implement.)

Beyond that, there's the "query" system, which is also used for key
functionality (including "Open with" to find supporting applications)
and also isn't supported by anything except BeFS (well, and Haiku's
RAMFS, but that doesn't really count, and also packagefs.)

There's other things beyond that, but those are the major bits, I think.

> No, for example there was a project called cosmoe with the aim of
> making the Haiku userland run on top of a POSIX OS. ... I tried
> this on (I think) NetBSD 6 and got it working to some extent but it
> was very unstable.

It's also very old; it's not from 2014, that repository is a source
import of a much older project (2004, maybe?)

So in addition to being written for a different era of the Linux/BSDs,
it's also using a base of Haiku sources that pre-date even R1/alpha1
(2009). Haiku in those days was far from being the relatively stable
and usable platform it is now, and I'd imagine that shows in Cosmoe
itself.

Probably of interest to you is a much more recent project called "HyClone":

https://github.com/trungnt2910/hyclone

This project can run Haiku's ELF binaries directly on Linux (by
implementing the syscall hooks, ioctls, etc. and implementing those
directly; it's not especially Linux specific, but as the README notes,
it should be portable to other SysV OSes, including Haiku itself.)
It's sophisticated enough that it can run Haiku's own app_server (in
headless mode) as well as client applications, as the screenshot in
its README demonstrates.

> All of this should be considered a concept or prototype at the moment.
> Anyhow, I was able to compile the original Haiku port IPC test
> programs and they all ran successfully.

This is definitely one area where I would recommend reading the Haiku
kernel source, because chances are there are going to be subtleties
there that the tests do not capture (our test suite is also not
especially complete, for that matter.) As most of Haiku is under the
MIT license (including the core kernel itself), licensing shouldn't be
a problem.

The source code for the ports implementation, specifically, is
primarily in this file:

https://github.com/haiku/haiku/blob/master/src/system/kernel/port.cpp

(Note that all the functions beginning _user_ are the syscall hooks,
so e.g. _user_get_port_info is the syscall implementation; in libroot
its hook will be called _kern_get_port_info.)

Hopefully some of this information is informative and/or helpful to
you. At any rate, if you intend to continue working on this, feel free
to hang out in our IRC channel (OFTC#haiku) and ask questions about
our sources, internals, etc.

-waddlesplash