add haiku support #1703

hoanga · 2022-04-23T05:06:26Z

hello,

the following changeset(s) adds support for compiling on haiku.

below is an sample run showing compilation

> uname -a
Haiku shredder 1 hrev56040 Apr 22 2022 06:24:48 x86_64 x86_64 Haiku

> cargo build
   Compiling autocfg v1.1.0
   Compiling libc v0.2.123
   Compiling bitflags v1.3.2
   Compiling cfg-if v1.0.0
   Compiling memoffset v0.6.5
   Compiling nix v0.24.1 (/boot/home/src/git/rust-libs/nix)
    Finished dev [unoptimized + debuginfo] target(s) in 11.09s

and some results from running cargo test:

running 32 tests
test sys::select::tests::fdset_clear ... ok
test sys::select::tests::fdset_insert ... ok
test sys::select::tests::fdset_highest ... ok
test sys::select::tests::fdset_fds ... ok
test sys::select::tests::fdset_remove ... ok
test sys::signal::tests::test_clear ... ok
test sys::select::tests::test_select ... ok
test sys::select::tests::test_select_nfds2 ... ok
test sys::signal::tests::test_contains ... ok
test sys::select::tests::test_select_nfds ... ok
test sys::signal::tests::test_extend ... ok
test sys::signal::tests::test_from_and_into_iterator ... ok
test sys::signal::tests::test_from_str_invalid_value ... ok
test sys::signal::tests::test_from_str_round_trips ... ok
test sys::signal::tests::test_sigaction ... ok
test sys::signal::tests::test_sigwait ... ok
test sys::signal::tests::test_thread_signal_set_mask ... ok
test sys::statvfs::test::fstatvfs_call ... ok
test sys::statvfs::test::statvfs_call ... ok
test sys::termios::test::try_from ... ok
test sys::signal::tests::test_thread_signal_swap ... ok
test sys::signal::tests::test_thread_signal_block ... ok
test sys::signal::tests::test_thread_signal_unblock ... ok
test sys::time::test::test_timespec ... ok
test sys::time::test::test_timespec_from ... ok
test sys::time::test::test_timespec_neg ... ok
test sys::time::test::test_timespec_fmt ... ok
test sys::time::test::test_timespec_ord ... ok
test sys::time::test::test_timeval ... ok
test sys::time::test::test_timeval_neg ... ok
test sys::time::test::test_timeval_fmt ... ok
test sys::time::test::test_timeval_ord ... ok

test result: ok. 32 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running test/test.rs (target/debug/deps/test-6e8a70ba3d8f7447)

running 73 tests
test sys::test_pthread::test_pthread_kill_none ... ok
test sys::test_pthread::test_pthread_self ... ok
test sys::test_select::test_pselect_nfds2 ... ok
test sys::test_select::test_pselect ... ok
test sys::test_signal::test_kill_none ... ok
test sys::test_signal::test_killpg_none ... ok
test sys::test_signal::test_old_sigaction_flags ... ok
test sys::test_signal::test_signal ... ok
test sys::test_signal::test_sigprocmask ... ok
test sys::test_signal::test_signal_sigaction ... ok
test sys::test_signal::test_sigprocmask_noop ... ok
test sys::test_select::test_fdset_negative_fd::contains - should panic ... ok
test sys::test_select::test_fdset_negative_fd::remove - should panic ... ok
test sys::test_select::test_fdset_negative_fd::insert - should panic ... ok
test sys::test_select::test_fdset_too_large_fd::contains - should panic ... ok
test sys::test_select::test_fdset_too_large_fd::insert - should panic ... ok
test sys::test_select::test_fdset_too_large_fd::remove - should panic ... ok
test sys::test_wait::test_wait_exit ... ok
test sys::test_wait::test_waitid_pid ... ok
test sys::test_uio::test_readv ... ok
test sys::test_wait::test_waitstatus_from_raw ... FAILED
test sys::test_wait::test_waitstatus_pid ... ok
test sys::test_uio::test_writev ... ok
test test_net::test_if_nametoindex ... ok
test test_dir::rewind ... ok
test test_poll::test_pollfd_events ... ok
test test_poll::test_pollfd_fd ... ok
test sys::test_uio::test_pwrite ... ok
test sys::test_uio::test_pread ... ok
test test_fcntl::test_readlink ... ok
test test_fcntl::test_openat ... ok
test test_dir::read ... ok
test test_stat::test_fstatat ... ok
test test_stat::test_mkdirat_fail ... ok
test test_time::test_clock_gettime ... ok
test test_stat::test_fchmod ... ok
test test_stat::test_fchmodat ... ok
test test_time::test_clock_id_now ... ok
test test_fcntl::test_renameat ... ok
test test_stat::test_mkdirat_success_path ... ok
test test_stat::test_stat_and_fstat ... ok
test test_unistd::test_execvpe::test_cstr_ref ... ok
test test_unistd::test_access_not_existing ... ok
test test_unistd::test_execvpe::test_cstring ... ok
test test_unistd::test_access_file_exists ... ok
test test_stat::test_stat_fstat_lstat ... ok
test test_unistd::test_fchdir ... ok
test test_unistd::test_fork_and_waitpid ... ok
test test_unistd::test_fchown ... ok
test test_unistd::test_chown ... ok
test test_unistd::test_getpid ... ok
test test_unistd::test_getsid ... ok
test test_unistd::test_fpathconf_limited ... ok
test test_unistd::test_lseek ... ok
test test_unistd::test_mkfifo_directory ... ok
test test_unistd::test_fchownat ... ok
test test_unistd::test_mkstemp_directory ... ok
test test_unistd::test_pathconf_limited ... ok
test test_unistd::test_pipe ... ok
test test_unistd::test_sysconf_limited ... ok
test test_unistd::test_mkfifo ... ok
test test_unistd::test_ttyname_not_pty ... ok
test test_unistd::test_ftruncate ... ok
test test_unistd::test_mkstemp ... ok
test test_poll::test_poll ... ok
test test_unistd::test_wait ... ok
test test_unistd::test_unlinkat_dir_removedir ... ok
test test_unistd::test_unlinkat_file ... ok
test test_unistd::test_unlinkat_dir_noremovedir ... ok
test test_unistd::test_truncate ... ok
test test_unistd::test_getcwd ... ok
test test_unistd::test_alarm ... ok
test test_unistd::test_canceling_alarm ... ok

failures:

---- sys::test_wait::test_waitstatus_from_raw stdout ----
thread 'sys::test_wait::test_waitstatus_from_raw' panicked at 'assertion failed: `(left == right)`
  left: `Ok(Exited(Pid(1), 2))`,
 right: `Ok(Signaled(Pid(1), SIGINT, false))`', test/sys/test_wait.rs:93:5


failures:
    sys::test_wait::test_waitstatus_from_raw

test result: FAILED. 72 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.06s

error: test failed, to rerun pass '--test test'

rtzoeller · 2022-04-24T20:23:01Z

@hoanga thanks for the pull request! I didn't have time to go through every file, but wanted to get you some feedback promptly. In particular, I was able to get through the following files:

Most of my concerns are around making sure we don't unnecessarily limit functionality that exists on Haiku just because it isn't in https://github.com/rust-lang/libc today. I'm not particularly familiar with Haiku though, so if any of my feedback is incorrect please let me know.

I'd also like to make sure the Haiku support doesn't regress over time, as it would appear to have done previously (there are existing references to "haiku" in the codebase). To that end, can you make changes similar to the ones made in #1603 to README.md, .cirrus.yml, and bors.toml to enable automated builds for x86_64-unknown-haiku?

hoanga · 2022-04-25T04:30:09Z

hi @rtzoeller! thanks for the feedback so far! i understand about the concerns regarding the Haiku port developing regressions over time and hope that won't be the case (if i can help prevent it). i have pushed some changes that hopefully enable the ci system to also enable builds for Haiku (for nightly, which might not be agreeing with Haiku). note the same changes builds on the stable version (1.60.0) that is installed on the Haiku i am testing with although am seeing the same messages pop up but they appear to be warnings with the version of Rust that comes with Haiku. EDIT: now building

part of my motivation for being able to get better haiku support in is that one of the tools (delta) that i am hoping can work on Haiku relies on the nix library. with a patch build of nix, delta has been surprisingly functional on my test Haiku system. below is some sample runs showing delta running on Haiku as well as a delta as a substitute for the built-in git diff on Haiku:

> delta --help | head
delta 0.12.0
A viewer for git and diff output

USAGE:
    delta [OPTIONS] [ARGS]

ARGS:
    <MINUS_FILE>
            First file to be compared when delta is being used in diff mode

> git diff .cirrus.yml 

Δ .cirrus.yml
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

─────────────┐
• 286: task: │
─────────────┘
    - name: OpenBSD x86_64
      env:
        TARGET: x86_64-unknown-openbsd
    - name: Haiku x86_64
      env:
        TARGET: x86_64-unknown-haiku
  setup_script:
    - rustup component add rust-src
  << : *BUILD

rtzoeller

Ugh, it looks like this feedback didn't actually get posted when I made the original comment the other day. My bad.

rtzoeller · 2022-04-24T19:49:33Z

src/errno.rs

@@ -767,6 +772,80 @@ fn desc(errno: Errno) -> &'static str {
    }
 }

+#[cfg(target_os = "haiku")]
+fn desc(errno: Errno) -> &'static str {


Instead of providing a Haiku-specific version of this function, can any Haiku-only (or missing on Haiku) errors be conditionally included in the existing definition of desc? It looks like there are only a few differences, and this is how other platform support is handled.

sure! i have merged desc function so there is no Haiku-specific version

rtzoeller · 2022-04-24T19:53:42Z

src/dir.rs

@@ -239,7 +239,7 @@ impl Entry {
        }

        // illumos and Solaris systems do not have the d_type member at all:


Update this comment as well.

rtzoeller · 2022-04-24T19:54:56Z

src/fcntl.rs

+        #[cfg(not(any(target_os = "redox", target_os = "haiku")))]
        #[cfg_attr(docsrs, doc(cfg(all())))]
        O_NDELAY;


It seems like Haiku defines this; does libc need to be updated?

https://github.com/haiku/haiku/blob/8f16317a5b6db5c672f331814273e5857555020f/headers/posix/fcntl.h#L50

after double checking, it looks like this is available in Haiku but the libc crate would need support for this. i have left this out for the time being.

rtzoeller · 2022-04-24T19:57:14Z

src/sys/mod.rs

@@ -52,7 +52,7 @@ feature! {
    pub mod memfd;
 }

-#[cfg(not(target_os = "redox"))]
+#[cfg(not(any(target_os = "redox", target_os = "haiku")))]
 feature! {
    #![feature = "mman"]
    pub mod mman;


It seems like Haiku probably supports some of the functionality contained in mman, such as madvise?

https://github.com/haiku/haiku/blob/8f16317a5b6db5c672f331814273e5857555020f/src/system/libroot/posix/sys/mman.cpp#L183-L188

i have put in some updates that should enable the parts that Haiku supports (sans mlockall)

I believe we also need to exclude munlockall.

rtzoeller · 2022-04-24T19:59:14Z

src/sys/mod.rs

+#[cfg(not(any(target_os = "redox", target_os = "fuchsia", target_os = "illumos", target_os = "haiku")))]
 feature! {
    #![feature = "resource"]


It seems like Haiku probably supports some of the functionality in resource, such as setrlimit?

https://github.com/haiku/haiku/blob/7d961f9746eccf7ec6268eb12af31fd1ea2db189/headers/posix/sys/resource.h#L81

i did try enabling it but ran into some errors that i think originate from the libc crate so leaving it out for now.

an example of the messages i saw looked like the following (if it helps):

error[E0412]: cannot find type `rlimit` in this scope --> src/sys/resource.rs:199:43 | 199 | let mut old_rlim = mem::MaybeUninit::<rlimit>::uninit(); | ^^^^^^ | ::: /boot/home/.cargo/registry/src/github.aaakk.us.kg-1ecc6299db9ec823/libc-0.2.123/src/unix/haiku/mod.rs:1:1 | 1 | pub type rlim_t = ::uintptr_t; | ------------------------------ similarly named type alias `rlim_t` defined here | help: a type alias with a similar name exists | 199 | let mut old_rlim = mem::MaybeUninit::<rlim_t>::uninit(); | ~~~~~~ help: consider importing one of these items | 2 | use crate::libc::rlimit; | 2 | use libc::rlimit;

rtzoeller · 2022-04-24T20:00:56Z

src/sys/mod.rs

+#[cfg(not(any(target_os = "redox", target_os = "haiku")))]
 feature! {
    #![feature = "socket"]
    #[allow(missing_docs)]


Can this be enabled for Haiku?

updated to enable socket

rtzoeller · 2022-04-24T20:04:43Z

src/sys/signal.rs

+        #[cfg(not(target_os = "haiku"))]
        SIGIO,


Suggested change

#[cfg(not(target_os = "haiku"))]

SIGIO,

#[cfg(not(target_os = "haiku"))]

#[cfg_attr(docsrs, doc(cfg(all())))]

SIGIO,

rtzoeller · 2022-04-24T20:05:58Z

src/sys/signal.rs

@@ -108,6 +109,7 @@ libc_enum!{
                      target_os = "redox")))]
        #[cfg_attr(docsrs, doc(cfg(all())))]
        /// Information request
+        #[cfg(not(target_os = "haiku"))]


Merge this into the existing cfg block.

rtzoeller · 2022-04-24T20:12:06Z

src/sys/socket/mod.rs

@@ -328,6 +328,7 @@ libc_bitflags!{
        #[cfg(any(target_os = "android",
                  target_os = "dragonfly",
                  target_os = "freebsd",
+                  target_os = "haiku",


I don't actually see MSG_CMSG_CLOEXEC in this list: https://github.com/haiku/haiku/blob/2bda927298d3491dcfe917de81b43ff85dd0c32d/headers/posix/sys/socket.h#L113-L124

Is it actually supported?

from what i understand, i don't think so have removed support in Haiku

rtzoeller · 2022-04-24T20:14:21Z

src/sys/statvfs.rs

        /// Read Only
+        #[cfg(not(target_os = "haiku"))]
        ST_RDONLY;
        /// Do not allow the set-uid bits to have an effect
+        #[cfg(not(target_os = "haiku"))]
        ST_NOSUID;


It seems like Haiku defines these?

https://github.com/haiku/haiku/blob/8f16317a5b6db5c672f331814273e5857555020f/headers/posix/sys/statvfs.h#L26-L27

after double checking, it looks like these are defined in Haiku but the libc crate would (also) need support for this

hoanga · 2022-05-01T17:33:38Z

thanks for the feedback! i have pushed updates and tried to respond to as much of the feedback as possible. some sections would likely need an update for the libc crate before support in Haiku could work properly. if the preference is to get these in libc before merging i can set this PR to WIP or such until they become available.

rtzoeller

some sections would likely need an update for the libc crate before support in Haiku could work properly.

My preference would be for Haiku support to be as complete as possible, but I also recognize that it can be tedious to add libc definitions for functions you will never personally use. Let's try to get the nix support up to parity with the existing libc definitions; if there are any missing symbols where adding one or two to libc would allow a module to be entirely feature-complete let's do that, otherwise we can code to libc's definition (except where it's wrong, which we've seen a few times already).

I think this is really close to being ready. If you can go through and revert any changes which are no longer necessary such as places adding an extra any(), that'd be helpful too.

Please add a CHANGELOG.md note as well in the Unreleased >> Added section.

rtzoeller · 2022-05-02T02:38:31Z

README.md

@@ -85,6 +85,7 @@ Tier 3:
  * x86_64-unknown-linux-gnux32
  * x86_64-unknown-openbsd
  * x86_64-unknown-redox
+  * x86_64-unknown-haiku


Please maintain alphabetical order (i.e. put this right below x86_64-unknown-dragonfly).

updated README for alphabetical order

rtzoeller · 2022-05-02T02:42:57Z

src/sys/mod.rs

@@ -52,7 +52,7 @@ feature! {
    pub mod memfd;
 }

-#[cfg(not(target_os = "redox"))]
+#[cfg(not(any(target_os = "redox", target_os = "haiku")))]
 feature! {
    #![feature = "mman"]
    pub mod mman;


I believe we also need to exclude munlockall.

rtzoeller · 2022-05-02T02:43:31Z

src/sys/mod.rs

@@ -126,7 +126,7 @@ feature! {
    pub mod signalfd;
 }

-#[cfg(not(target_os = "redox"))]
+#[cfg(not(any(target_os = "redox")))]


This line can be reverted; we don't need any for just one platform.

updated and munlockall also excluded

rtzoeller · 2022-05-02T02:44:33Z

src/sys/socket/addr.rs

@@ -120,6 +121,7 @@ pub enum AddressFamily {
    #[cfg_attr(docsrs, doc(cfg(all())))]
    Rose = libc::AF_ROSE,
    /// DECet protocol sockets.
+    #[cfg(not(any(target_os = "haiku")))]


Don't need any.

rtzoeller · 2022-05-02T02:44:38Z

src/sys/socket/addr.rs

@@ -151,6 +153,7 @@ pub enum AddressFamily {
    #[cfg_attr(docsrs, doc(cfg(all())))]
    Rds = libc::AF_RDS,
    /// IBM SNA
+    #[cfg(not(any(target_os = "haiku")))]


Don't need any.

rtzoeller · 2022-05-02T02:58:32Z

src/sys/termios.rs

        assert_eq!(Ok(BaudRate::B0), BaudRate::try_from(libc::B0));
+        #[cfg(not(target_os = "haiku"))]
        assert!(BaudRate::try_from(999999999).is_err());


I'm guessing this is because Haiku uses a u8, and 999999999 isn't valid. Can the test use a different invalid number on Haiku, rather than disabling this part of it? E.g. assert!(BaudRate::try_from(99).is_err()); on Haiku?

adding a check for haiku sounds good to me. i have added the recommended assert! for the haiku-specific case

rtzoeller · 2022-05-02T02:59:34Z

src/time.rs

@@ -42,7 +42,7 @@ impl ClockId {
    }

    /// Returns resolution of the clock id
-    #[cfg(not(target_os = "redox"))]
+    #[cfg(not(any(target_os = "redox", target_os = "haiku")))]
    #[cfg_attr(docsrs, doc(cfg(all())))]
    pub fn res(self) -> Result<TimeSpec> {
        clock_getres(self)


Haiku seems to support this.

i tried enabling it but ran into messages like the one below. think this is a case of the functions being available in haiku but not necessarily available in libc:

error[E0425]: cannot find function `clock_getres` in crate `libc` --> src/time.rs:220:30 | 220 | let ret = unsafe { libc::clock_getres(clock_id.as_raw(), c_time.as_mut_ptr()) }; | ^^^^^^^^^^^^ help: a function with a similar name exists: `clock_gettime` |

rtzoeller · 2022-05-02T03:00:34Z

src/time.rs

@@ -212,7 +212,7 @@ impl std::fmt::Display for ClockId {

 /// Get the resolution of the specified clock, (see
 /// [clock_getres(2)](https://pubs.opengroup.org/onlinepubs/7908799/xsh/clock_getres.html)).
-#[cfg(not(target_os = "redox"))]
+#[cfg(not(any(target_os = "redox", target_os = "haiku")))]
 #[cfg_attr(docsrs, doc(cfg(all())))]
 pub fn clock_getres(clock_id: ClockId) -> Result<TimeSpec> {


Haiku seems to support this.

i think this is a similar situation as above, haiku does support it but seems like libc does not

rtzoeller · 2022-05-02T03:09:25Z

src/unistd.rs

@@ -2986,7 +2988,7 @@ impl From<User> for libc::passwd {
    }
 }

-#[cfg(not(target_os = "redox"))] // RedoxFS does not support passwd
+#[cfg(not(any(target_os = "redox", target_os = "haiku")))] // RedoxFS does not support passwd


I see a definition for getpwnam_r in libc; can we make Haiku support all of these (including the From impls above)?

sure, i gave it another shot and looks like this attempt was more successful than earlier attempts.

rtzoeller · 2022-05-02T03:09:37Z

test/sys/mod.rs

@@ -11,21 +11,21 @@ mod test_signal;
          target_os = "macos",
          target_os = "netbsd"))]
 mod test_aio;
-#[cfg(not(target_os = "redox"))]
+#[cfg(not(any(target_os = "redox")))]


Don't need any.

hoanga · 2022-05-03T04:58:36Z

thanks again for the prompt feedback! i have pushed more updates that should help address this round of feedback and enabled some more functionality for haiku.

just for note, a few more tests have been enabled with these updates (the non-passing test is the same one):

test result: FAILED. 77 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.08s

hoanga · 2022-05-07T04:59:58Z

looks like the most recent libc release also included haiku updates for clock, i have enabled that functionality and the associated tests which are passing at this time. cargo test now reports:

running 80 tests
...
...
...
test result: FAILED. 79 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.05s

rtzoeller

@hoanga the changes look good! Can you amend the CHANGELOG entry to be of the form

- Added support for the `x86_64-unknown-haiku` target.
(#[1703](https://github.com/nix-rust/nix/pull/1703))

and then squash all of the commits into one?

Thanks!

hoanga · 2022-05-10T03:32:29Z

i have pushed an update for the changelog as well as combining the previous commits into a squashed commit. thanks for all the feedback!

rtzoeller · 2022-05-14T16:24:41Z

@hoanga it looks like #1699 made this unmergeable, can you rebase?

* enabled as much functionality and defines that match updated libc definitions for haiku

rtzoeller · 2022-05-15T00:19:46Z

bors r+

bors · 2022-05-15T00:37:37Z

hoanga mentioned this pull request Apr 23, 2022

please add haiku support #1704

Closed

rtzoeller reviewed May 1, 2022

View reviewed changes

rtzoeller reviewed May 2, 2022

View reviewed changes

hoanga force-pushed the haiku-support branch from 00655d9 to 54b2047 Compare May 3, 2022 04:56

rtzoeller reviewed May 9, 2022

View reviewed changes

hoanga force-pushed the haiku-support branch from 599ac91 to 55333e4 Compare May 10, 2022 03:13

add haiku support

d02e274

* enabled as much functionality and defines that match updated libc definitions for haiku

hoanga force-pushed the haiku-support branch from 55333e4 to d02e274 Compare May 14, 2022 23:58

bors bot merged commit 1647189 into nix-rust:master May 15, 2022

		@@ -239,7 +239,7 @@ impl Entry {
		}

		// illumos and Solaris systems do not have the d_type member at all:

add haiku support #1703

add haiku support #1703

Conversation

hoanga commented Apr 23, 2022

rtzoeller commented Apr 24, 2022

hoanga commented Apr 25, 2022 • edited Loading

rtzoeller left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hoanga commented May 1, 2022

rtzoeller left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hoanga commented May 3, 2022

hoanga commented May 7, 2022

rtzoeller left a comment

Choose a reason for hiding this comment

hoanga commented May 10, 2022

rtzoeller commented May 14, 2022

rtzoeller commented May 15, 2022

bors bot commented May 15, 2022

hoanga commented Apr 25, 2022 •

edited

Loading