Haiku: add definitions for the Haiku's native sytem API. #2034
Conversation
|
r? @JohnTitor (rust-highfive has picked a reviewer for you, use r? to override) |
|
@kallisti5 @jessicah @ahwayakchih Since you have contributed to the Haiku bindings before, could you have a look and perhaps add some comments? |
|
I'm working on the style and semantic issues pointed out by the CI. |
|
Changes since previous push:
This change is ready for review. |
|
@JohnTitor This one's looking pretty solid and fills in a lot of missing base libc stuff from Haiku. Thoughts? |
|
Hey, thanks for PR! @nielx Do you want me to make a new relase for |
|
@JohnTitor That would be appreciated. I have some follow-up work to this commit that adds support for libc-test and that applies some fixes that it pointed out, so if there is a ctest2 package that supports Haiku, it will allow others to reproduce the tests and build on that work. |
|
Okay, published ctest2 0.4.0. |
On the Haiku platform, the POSIX (and BSD) API coexists with the native API, that has its origins on the BeOS platform. Unlike other UNIX-like platforms, the native API is not an extension of the POSIX API, but instead exists sui generis, and many of the POSIX concepts have their own native variety, with relatively limited interoperability. Nontheless, the native API coexists in the same library as the standard C and POSIX functions, namely libroot.so, and therefore this crate is a good place to add bindings to it. This commit implements most of Haiku's support kit, the most important parts of the kernel kit, and a part of the storage kit.
nielx
force-pushed
the
haiku-native
branch
2 times, most recently
from
c1b2e0d to
b4262af
Compare
No changes to other platforms.
|
I added support for Haiku in the testing framework, and the fixes for the issues that it pointed out. |
|
@JohnTitor Anything I can do to help you progress this? |
|
Hey, thanks for the ping! |
It should be possible to set up a cross-compiling CI configuration to build libc for Haiku. I don't think it is possible to build and run the tests that way. Haiku is not (yet) virtualizable friendly, so I there's not such a thing as a Haiku VM image yet. I do wonder what the relative value of a continuous CI build would be, but we can certainly try to set it up.
The old definitions have always been incorrect. |
|
@bors r+ |
|
📌 Commit 813d7d8 has been approved by |
|
☀️ Test successful - checks-actions, checks-cirrus-freebsd-11, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13 |
On the Haiku platform, the POSIX (and BSD) API coexists with the native API,
that has its origins on the BeOS platform. Unlike other UNIX-like platforms,
the native API is not an extension of the POSIX API, but instead exists sui
generis, and many of the POSIX concepts have their own native variety, with
relatively limited interoperability.
Nonetheless, the native API coexists in the same library as the standard C and
POSIX functions, namely libroot.so, and therefore this crate is a good place
to add bindings to it.
This commit implements most of Haiku's support kit, the most important parts
of the kernel kit, and a part of the storage kit.