nix-rust/nix

Rust friendly bindings to *nix APIs

Rust bindings to *nix APIs

Documentation (Releases)

Nix seeks to provide friendly bindings to various *nix platform APIs (Linux, Darwin, ...). The goal is to not provide a 100% unified interface, but to unify what can be while still providing platform specific APIs.

For many system APIs, Nix provides a safe alternative to the unsafe APIs exposed by the libc crate. This is done by wrapping the libc functionality with types/abstractions that enforce legal/safe usage.

As an example of what Nix provides, examine the differences between what is exposed by libc and nix for the gethostname system call:

// libc api (unsafe, requires handling return code/errno)
pub unsafe extern fn gethostname(name: *mut c_char, len: size_t) -> c_int;

// nix api (returns a nix::Result<OsString>)
pub fn gethostname() -> Result<OsString>;

Supported Platforms

nix target support consists of three tiers. While nix attempts to support all platforms supported by libc, only some platforms are actively supported due to either technical or manpower limitations. Support for platforms is split into three tiers:

• Tier 1 - Builds and tests for this target are run in CI. Failures of either block the inclusion of new code.
• Tier 2 - Builds for this target are run in CI. Failures during the build blocks the inclusion of new code. Tests may be run, but failures in tests don't block the inclusion of new code.
• Tier 3 - Builds for this target are run in CI. Failures during the build do not necessarily block the inclusion of new code. That is, at our discretion a Tier 3 target may be dropped at any time, if it would otherwise block development.

Platforms not listed are supported on a best-effort basis, relying on our users to report any problems.

The following targets are supported by nix:

Tier 1	Tier 2	Tier 3
aarch64-apple-darwin aarch64-unknown-linux-gnu arm-unknown-linux-gnueabi armv7-unknown-linux-gnueabihf i686-unknown-freebsd i686-unknown-linux-gnu i686-unknown-linux-musl mips-unknown-linux-gnu mips64-unknown-linux-gnuabi64 mips64el-unknown-linux-gnuabi64 mipsel-unknown-linux-gnu powerpc64le-unknown-linux-gnu x86_64-unknown-freebsd x86_64-unknown-linux-gnu x86_64-unknown-linux-musl	aarch64-apple-ios aarch64-linux-android arm-linux-androideabi arm-unknown-linux-musleabi armv7-linux-androideabi i686-linux-android s390x-unknown-linux-gnu x86_64-linux-android x86_64-unknown-illumos x86_64-unknown-netbsd	armv7-unknown-linux-uclibceabihf powerpc64-unknown-linux-gnu x86_64-fuchsia x86_64-unknown-dragonfly x86_64-unknown-haiku x86_64-unknown-linux-gnux32 x86_64-unknown-openbsd x86_64-unknown-redox i686-unknown-hurd-gnu

Minimum Supported Rust Version (MSRV)

nix is supported on Rust 1.69 and higher. Its MSRV will not be changed in the future without bumping the major or minor version.

Contributing

Contributions are very welcome. Please See CONTRIBUTING for additional details.

Feel free to join us in the nix-rust/nix channel on Gitter to discuss nix development.

License

Nix is licensed under the MIT license. See LICENSE for more details.

nix's Issues

ARM fix

I recently compiled nix for my beagleboard black - it went smoothly, but I got two compile errors, both in uio.rs.

The parameter offset to ffi::pread and ffi::pwrite are i32 on my arm. Maybe they should be isize? I am not sure how to express that in rust in a portable manner.

Ptrace support

It be really helpful if this library had support for sys/ptrace

mq support might be broken

Hello,

After trying to add support for mq_getattr I realized that mq_open might be broken. This has probably to do with the varargs call. It all looks ok but I am not sure if it is really done correctly. mq_open takes a var_args at the end for the mode_t and mq_attr arguments.

For now do not use it in production!

See also the discussion here:
https://users.rust-lang.org/t/problem-with-calling-c-code/1954/12

A unit test that I am trying to write for mq_getattr results in an illegal instruction (SIGNAL 4).
It is likely that the mq_open call is somehow messing up the stack.

Any hints on how to correctly pass var_args to an external C function is appreciated.

Markus

Add a license/copyright info

Several `const`s should be `bitflags`

Some random examples (there are many more):

• MmapFlag
• MmapProt
• SockMessageFlags

Publish new version (0.3.6?) to crates.io

I would like to publish an initial version of my spidev crate (https://github.com/posborne/rust-spidev/tree/master), but that is dependent on the new ioctl code. Publishing a new version would be appreciated.

Improve ARM support

This really requires CI infrastructure. I filed an issue with Travis: travis-ci/travis-ci#3376. Also, it would require ARM builds of Rust, etc...

Figure out the future of nix

tl;dr Should nix be split up into multiple crates named nix-* and what should the API style be?

The situation

Nix originated as a posix binding dumping ground for various crates that I had been working on. I tended to need the same bindings over and over again, so I just moved them into Nix. I thought this would be useful for other people, so I accepted PRs for various system APIs as they have been submitted.

Everything has been fine so far, but a few issues have arisen.

As the API coverage has increased, whenever a breaking change is made, the semver must be incremented. So, if the ioctl module changes an API as it figures out the best way to expose functionality, the version must be bumped and downstream crates must change their dependencies. For example, Mio depends on nix, but not on any ioctl features, so bumping the dependency is pretty annoying.

Secondly, the API style has been somewhat ad hoc, especially with more complicated system APIs like fcntl.

Crate structure

There is value in having a single place (nix) to find system APIs that have a coherent API style and a single documentation site. I think that each specific API silo, like sockets, ioctl, mqueue, signals, etc... could be in their own crate named nix_*. Common features like errors, NixPath, etc... would live in nix_core. The nix crate would be a facade depending on all the sub crates with liberal dependencies (probably "*") which would allow the consumer to optionally be able to pin each sub crate to whatever.

Libraries like Mio could then depend only on the features that are needed.

Also, it would allow delegating responsibility better. I, for one, know nothing about ioctl. I would like to stop being the blocker.

API style

This is still something that I haven't figured out. I do know that the goal of nix is *comprehensive, safe, zero cost bindings to system APIs on nix OSes.

So, what does that mean for nix? As of now, there are currently a variety of styles. For example, most APIs are 1-1 bindings to the equivalent OS api. This leads to APIs like fcntl which uses a convoluted FcntlArg strategy. ioctl on the other hand uses a (fairly impressive) macro...

The question is, would it be better to expand beyond the 1-1 rule. For example, in the fnctl case, the API would most likely be much cleaner and more "rusty" if each "fcntl arg" was moved to an individual function. There could, for example, be a public fcntl mod with a dupfd function. Using it would be:

let res = fcntl::dup_fd(fd);

Then, should it go further? Should there be an Fd type that wraps std::os::unix::RawFd and implement functions like dup directly on that type?

These are all open questions that I pose to the users of nix.

cc @posborne @cmr @geofft @utkarshkukreti @MarkusJais and whoever else :)

`impl AsExtStr for OsStr` does not convert to a proper C string

I started noticing some strange behavior when trying to use the lstat function I recently submitted; lstat seemed to be returning ENOENT when the file did indeed exist, and opened correctly with File::open(). I began investigating, and I think I've found the cause: the implementation of AsExtStr for OsStr:

/// Converts a value to an external (FFI) string representation
trait AsExtStr {
    fn as_ext_str(&self) -> *const libc::c_char;
}

impl AsExtStr for OsStr {
    fn as_ext_str(&self) -> *const libc::c_char {
        self.as_bytes().as_ptr() as *const libc::c_char
    }
}

It appears the problem is that this just borrows the byte slice from the OsStr and then simply casts to a libc::c_char. If I am not mistaken, believe that this does not properly convert to a null-terminated C string. I was able to construct a rather interesting test case which showcases this (you can paste this at the bottom of src/lib.rs to test for yourself):

#[cfg(test)] use libc::funcs::c95::stdio;
#[cfg(test)] use std::ffi::CStr;
#[test]
#[allow(unused_variables)]
fn test_as_ext_str() {
    let foo_str = "foo";
    let bar_str = "bar";
    let s = Path::new(foo_str).as_os_str();
    let ext_str = s.as_ext_str();
    unsafe { stdio::puts(ext_str); }
    let cstr = unsafe { CStr::from_ptr(ext_str) };
    let back_to_str = std::str::from_utf8(cstr.to_bytes()).unwrap();
    assert_eq!(foo_str, back_to_str);
}

This is the output:

dead10ck at arch-laptop in ~/src/rust/nix-rust (master●)
$ cargo test test_as_ext_str
     Running target/debug/nix-21d2363c10db6dc6

running 1 test
foobarsrc/lib.rs
test test_as_ext_str ... FAILED

failures:

---- test_as_ext_str stdout ----
    thread 'test_as_ext_str' panicked at 'assertion failed: `(left == right)` (left: `"foo"`, right: `"foobarsrc/lib.rs"`)', src/lib.rs:167



failures:
    test_as_ext_str

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured

thread '<main>' panicked at 'Some tests failed', /home/rustbuild/src/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libtest/lib.rs:259

You can see just below the running 1 test line the output of the call to libc's puts function. The input string was "foo", but because the pointer that as_ext_str returned was not properly null-terminated, it also printed out some other strings that were adjacent in memory.

This will likely be non-trivial to fix, since AsExtStr is used in many places throughout the crate; a proper CStr or CString will probably need to be constructed from the OsStr argument, and that should be returned instead of a raw pointer. What do you think?

ioctl call with nix 0.4.*

Hello,

What it is the equivalent in version 0.4.* to the following call in version 0.3.*:

ioctl::read_into(libc::STDOUT_FILENO, TIOCGWINSZ, &mut size)

(https://github.com/gwenn/rustyline/blob/master/src/lib.rs#L185)

Thanks

Strange build issue with libc

Hi,

I get this error message:

failed to select a version for libc (required by rand):
all possible versions conflict with previously selected versions of libc
version 0.1.10 in use by libc v0.1.10
possible versions to select: 0.1.5

Very strange. I played with version numbers, no change.

I doubt that this is a nix-rust issue because there was something similar with mio and cargo a while ago:

rust-lang/cargo#1800

But that is closed. Maybe this is a different problem.

Tested with both 1.2 and 1.4 nightly.

Markus

Doesn't support abstract UNIX sockets

To use a socket in the abstract namespace, one bind()s a socket to a path beginning with a NUL byte. Unfortunately, there's an explicit test that fails on a NUL encountered in a path. Additionally, functions like strcpy() are called in parts of the library, and won't work if there's a NUL that's not the last byte in the string.

Additional Signal codes

Is there a reason why there aren't some signals like SIGSTP? I want to handle ctrl+z as well. Is there a standard that we are completing or have these ones just been specifically chosen at https://carllerche.github.io/nix-rust/nix/sys/signal/index.html ? Thanks guys.

cpuset_attribs not defined for ARM Linux

No cpuset_attributes are defined for arch "arm" and os "linux". This results in compilation errors when cross-compiling for triples like "arm-unknown-linux-gnueabihf" used by boards like the raspberry pi and beaglebone black.

I copied the cpuset_attribs from android and these worked for my use case.

   Compiling nix v0.3.3
.../nix-0.3.3/src/sched.rs:94:25: 94:52 error: failed to resolve. Use of undeclared type or module `cpuset_attribs`
.../nix-0.3.3/src/sched.rs:94     cpu_mask: [CpuMask; cpuset_attribs::CPU_SETSIZE/cpuset_attribs::CPU_MASK_BITS]

please generate latest package on crates.io

Compling other library requiring the latest nix-rust, please generate latest package on crates.io.

Thank you. :)

Make ioctl usable for more than just TIOCGWINSZ

The version of ioctl that is currently present in nix is not particularly useful (only has support for TIOCGWINSZ) and the design would require that the library itself be modified in order to add additional ioctls. I would like to see nix support a good lower-level ioctl implementation that can be used to raise the level of abstraction for any rust code that needs to send ioctls to regular and special files.

My immediate need for something like this is in implementing a library that provides access to Linux spidev devices (https://www.kernel.org/doc/Documentation/spi/spidev / http://lxr.free-electrons.com/source/include/uapi/linux/spi/spidev.h), but there are many, many devices out there that require ioctl for normal operation. I think there is probably some interface that can be provided that provides a little more help to implementers than what is currently available (and more than the libc ioctl).

A good starting place seems to be looking at the low-level macros available in the ioctl header: http://lxr.free-electrons.com/source/include/uapi/asm-generic/ioctl.h

I am going to play with things and see if I can come up with a more concrete proposal for a refined design for ioctls.

Properly bring back `mount`

Bring back mount w/ tests for the various permutation of arguments

compile failure against latest version of libc

libc 0.1.9 was just released, and nix on linux is failing to compile against it:

Compiling nix v0.3.9 (file:///vagrant/nix-rust)
src/sys/ioctl.rs:204:38: 204:57 error: mismatched types:
 expected `u64`,
    found `i32`
(expected u64,
    found i32) [E0308]
src/sys/ioctl.rs:204     convert_ioctl_res(libc_ioctl(fd, op as os_ioctl_op_t, data_ptr))
                                                          ^~~~~~~~~~~~~~~~~~~
src/sys/ioctl.rs:204:38: 204:57 help: run `rustc --explain E0308` to see a detailed explanation
src/sys/ioctl.rs:216:38: 216:57 error: mismatched types:
 expected `u64`,
    found `i32`
(expected u64,
    found i32) [E0308]
src/sys/ioctl.rs:216     convert_ioctl_res(libc_ioctl(fd, op as os_ioctl_op_t, data as *const T))
                                                          ^~~~~~~~~~~~~~~~~~~
src/sys/ioctl.rs:216:38: 216:57 help: run `rustc --explain E0308` to see a detailed explanation
src/sys/ioctl.rs:223:47: 223:66 error: mismatched types:
 expected `u64`,
    found `i32`
(expected u64,
    found i32) [E0308]
src/sys/ioctl.rs:223     convert_ioctl_res(unsafe { libc_ioctl(fd, op as os_ioctl_op_t) })
                                                                   ^~~~~~~~~~~~~~~~~~~
src/sys/ioctl.rs:223:47: 223:66 help: run `rustc --explain E0308` to see a detailed explanation
error: aborting due to 3 previous errors
Could not compile `nix`.

What happened with eventfd?

I used eventfds as a building block (for benchmarks in my fdringbuf crate), and found that it was suddenly gone (to make it compile on the beta, according to a recent commit).

I'm not really sure what the problem is and if it's easy to bring it back, both on the nightly and on the beta...?

Intermittent failures running cargo test

I was trying to track down some intermittent failures with some new tests I was writing and write a script to run cargo test over and over. With master I see 3 distinct failures signatures:

1. This is due to an off-by-one error in sys::test_uio::test_readv. I have a change to fix this and will submit a PR.
   failures:

   ---- sys::test_uio::test_readv stdout ----
   thread 'sys::test_uio::test_readv' panicked at 'Rng.gen_range called with low >= high', /home/joseph/.cargo/registry/src/github.com-0a35038f75765ae4/rand-0.3.8/src/lib.rs:441
   
   
   
   failures:
   sys::test_uio::test_readv
   

2. I think this is due to tests running tests in parallel and wait() waking up for a different child than expected. Is there a way to run tests in isolation?
   failures:

   ---- test_unistd::test_wait stdout ----
       thread 'test_unistd::test_wait' panicked at 'assertion failed: `(left == right)` (left: `Ok(Exited(21710))`, right: `Ok(Exited(21714))`)', test/test_unistd.rs:41
   
   
   ---- test_unistd::test_execve stdout ----
       thread 'test_unistd::test_execve' panicked at 'called `Result::unwrap()` on an `Err` value: Sys(ECHILD)', ../src/libcore/result.rs:731
   
   
   
   failures:
       test_unistd::test_execve
       test_unistd::test_wait
   

3. This one takes longer to reproduce. I'm not sure what the problem is here.
   failures:

   ---- sys::test_termios::test_tcgetattr stdout ----
       thread 'sys::test_termios::test_tcgetattr' panicked at 'assertion failed: `(left == right)` (left: `Some(Sys(ENOTTY))`, right: `Some(Sys(EBADF))`)', test/sys/test_termios.rs:15
   
   
   
   failures:
       sys::test_termios::test_tcgetattr
   

Please let me know if I should file 3 separate issues for these.

Publish new package on crates.io

FromPrimitive is gone from rustc nightly, so a new package is needed.

Rename NixResult -> Result (same w/ NixError)

bind sendmsg/recvmsg for Unix socket control messages/ancillary data

Right now nix exposes bindings to sendto/recvfrom which work for the data part of Unix socket messages, but which cannot interact with control messages such as file descriptors sent over Unix sockets. The library should also bind these as they're one of the distinguishing features of Unix sockets.

`sigaction` should probably be `unsafe`

If you access thread-local data in a signal handler or panic, you probably invoke UB.

http://users.rust-lang.org/t/unix-signals-in-rust/733/3

Illegal hardware instruction on Mac OS when using signals

Hi. I have the following program

extern crate nix;
extern crate libc;

use std::thread;
use nix::sys::signal;

extern "C" fn handle_signal(val: libc::c_int) {
    println!("Handling");
}

fn main() {
    let sig_action = signal::SigAction::new(
        handle_signal,
        signal::SockFlag::empty(),
        signal::SigSet::empty()
        );
    unsafe { let _ = signal::sigaction(signal::SIGINT, &sig_action).unwrap(); }
    loop {
        thread::sleep_ms(100);
    }
}

When I run this program and hit ^C I get the output "Illegal instruction: 4" and the program crashes

My system information is
libc: v0.1.8
nix: v0.3.7
Mac OS: 10.10.3
rustc --version: 1.2.0-nightly (9ad0063a1 2015-06-20)

I believe this has to do with the implementation of sigaction. When I reimplement this struct myself like so the sigaction function call works

#[repr(C)]
pub struct sigaction {
    pub sa_handler: extern fn(libc::c_int),
    pub sa_sigaction: extern fn(libc::c_int, *mut siginfo_t, *mut libc::c_void),
    pub sa_mask: sigset_t,
    pub sa_flags: libc::c_int,
    pub sa_restorer: extern fn(),
}

type sigaction_t = self::sigaction;

Thanks in advance

getpeername() panics on AF_UNIX sockets because sockaddr_un varies in size

extern crate nix;
use nix::sys::socket::*;
use nix::unistd::*;

fn main() {
    let (fd1, fd2) = socketpair(AddressFamily::Unix, SockType::Stream, 0, SockFlag::empty()).unwrap();
    getpeername(fd1).unwrap();
}

does this:

geofft@titan:~/src/rust/scratch/t$ target/debug/t
thread '<main>' panicked at 'assertion failed: len as usize == mem::size_of::<sockaddr_un>()', /home/geofft/src/rust/nix-rust/src/sys/socket/mod.rs:721

The panic is in sockaddr_storage_to_addr:

        consts::AF_UNIX => {
            assert!(len as usize == mem::size_of::<sockaddr_un>());
            Ok(SockAddr::Unix(UnixAddr(*(addr as *const _ as *const sockaddr_un))))
        }

From some print statements, it looks like len is 2, whereas the size of the structure is 110. strace traces this as

getpeername(3, {sa_family=AF_LOCAL, NULL}, [2]) = 0

It looks like it's valid for a sockaddr_un to report a length shorter than the maximum size, and we're supposed to treat this as a flexible array member or something. The easiest answer may be for UnixAddr to explicitly track its own size, although I'm wondering if really SockAddr should track size for all variants.

Probably a prereq for / should be fixed alongside #169.

(Also, getpeername has no tests and probably should have at least one.)

unistd::pivot_root() is possibly broken

While implementing a fix for #117, I noticed that unistd::pivot_root() is possibly broken.

On 9 Feb, effb423 introduced the NixPath trait, which at first took a closure which has a *const libc::c_char as an argument, and unistd::pivot_root() was changed to use with_nix_path() and its closure's arguments as arguments in the call to sys::syscall::syscall().

Then on 26 Feb, e8a58c8 changed NixPath to take an &OsStr instead of a *const libc::c_char, but unistd::pivot_root() was not updated. So it appears that unistd::pivot_root() is now passing &OsStrs to sys::syscall::syscall(). I imagine this wasn't caught because unistd::pivot_root() doesn't appear to be covered by any unit tests.

interested in mq support (Posix message queues)?

Hi,

I am interested in providing Rust bindings to the Posix message queues.

Would this be something for nix-rust?

I would love to add this.

Markus

Any plans for new release?

In particular I'm interested in waitpid and clone functions which were recently fixed. I'm asking because it blocks releasing of my unshare crate which deals with linux containers.

ioctl! macro does not allow definition of public ioctl wrappers

There doesn't seem to be an easy way to simply make public the generated ioctl wrappers without essentially duplicating all of their work (writing wrapping functions with the appropriate signature)

An easy way to prefix with 'pub' would be nice.

statvfs and fstatvfs support

There is no way to get file system statistic information in Rust. It would be great if nix-rust supports these system calls.

please release a new version soon?

I was using the released crate and just got bitten by #117. 😄

SockOpt should be separated into two traits, getter and setter

Currently, SockOpt has get and set methods. But some of the options, such as

1. SO_ERROR
2. SO_DOMAIN
3. ...

are read-only, which require to provide a valid value length when calling getsockopt.

In sys/socket/sockopt.rs, the implementation of Get<T>::unwrap will check the return length, but if you don't set the correct length before you call the getsockopt, actually it will just do nothing and return zero.

Here is a test snippet in C

#include <sys/socket.h>
#include <sys/types.h>
#include <fcntl.h>
#include <netinet/in.h>
#include <arpa/inet.h>

#include <errno.h>

#include <unistd.h>

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char *argv[]) {


    int sock = socket(AF_INET, SOCK_STREAM, 0);

    fcntl(sock, F_SETFL, fcntl(sock, F_GETFL, 0) | O_NONBLOCK);

    struct sockaddr_in s_addr;
    memset(&s_addr, 0, sizeof(s_addr));
    s_addr.sin_family = AF_INET;
    // This is an invalid address, should return ECONNREFUSED
    s_addr.sin_addr.s_addr = inet_addr("127.0.0.1");
    s_addr.sin_port = htons(12345);
    socklen_t addr_len = sizeof(struct sockaddr_in);

    int ret = connect(sock, (struct sockaddr *)&s_addr, addr_len);
    if (ret != 0) {
        if (errno != EINPROGRESS) {
            perror("connect");
            return EXIT_FAILURE;
        }
    }

    sleep(1); // Just sleep for 1 sec.

    int result = 0;
    socklen_t len = sizeof(result); // Try to set len = 0, getsockopt won't fill it with the correct length.

    if (getsockopt(sock, SOL_SOCKET, SO_ERROR, &result, &len) != 0) {
        perror("getsockopt");
        return EXIT_FAILURE;
    }

    printf("%d %d\n", result, len);

    return 0;
}

mismatched types: expected `int`, found `uint`

With the recent Rust:

   Compiling num v0.0.1 (https://github.com/rust-lang/num#da2fcbaa)
/home/dtantsur/.cargo/git/checkouts/nix-rust-f423826171ff8c33/master/src/errno.rs:17:24: 17:31 error: mismatched types: expected `int`, found `uint` (expected int, found uint)
/home/dtantsur/.cargo/git/checkouts/nix-rust-f423826171ff8c33/master/src/errno.rs:17         match from_int(errno()) {

epoll_create1 support

Add a conditional compilation system to allow features available only on some platforms.

I removed a number of bindings that were not generally portable in order to get everything compiling on Rust 1.0 beta. These should be brought back.

epoll does not work on Raspberry Pi

Hi,

I'm facing problems with epoll on Raspberry Pi. I've figured out it's due to different size of the EpollEvent structure. The structure defined in rust comes out packed but the native structure is not packed (i.e. it's 16 bytes wide). In my opinion, it's common pattern for the whole arm architecture, so the code in sys/epoll.rs should be changed to something like this:

#[cfg(target_arch = "arm")]
#[derive(Clone, Copy)]
#[repr(C)]
pub struct EpollEvent {
    ...
}

#[cfg(target_arch = "arm")]
#[test]
fn test_epoll_event_size() {
    ...
}

#[cfg(not(target_arch = "arm"))]
#[derive(Clone, Copy)]
#[repr(C, packed)]
pub struct EpollEvent {
    ...
}

I can send you a pull request if you want.

Build fails on latest nightly

rust-lang/rust#24461 seems to have broken the build on nightly. The impls generated by thesockopt_impl macro violate this. I'm trying to find a good way to fix this, but my macro-fu is pretty weak.

sys::epoll::EpollEvent needs #[derive(Clone, Copy)] for Android as well

Hi,

I failed to cross-compile nix 0.3.9 for arm-linux-androideabi on a rustc 1.1.0-dev. The error message was error: the trait core::clone::Cloneis not implemented for the typesys::epoll::EpollEvent [E0277].

Looking at src/sys/epoll.rs it seems that EpollEvent is missing a derive(Clone) for cfg(all(target_os = "android", not(target_arch = "x86_64"))).

sigaction struct on OS X

I've been looking on signal-handling code in nix-rust to implement signal support in mio and it seems that sigaction struct definition for OS X is a bit off.

Relevant definition from 10.10:

/* union for signal handlers */
union __sigaction_u {
        void    (*__sa_handler)(int);
        void    (*__sa_sigaction)(int, struct __siginfo *,
                       void *);
};

/* Signal vector template for Kernel user boundary */
struct  __sigaction {
        union __sigaction_u __sigaction_u;  /* signal handler */
        void    (*sa_tramp)(void *, int, int, siginfo_t *, void *);
        sigset_t sa_mask;               /* signal mask to apply */
        int     sa_flags;               /* see signal options below */
};

/*                                                                                                                                                                              
 * Signal vector "template" used in sigaction call.                                                                                                                             
 */
struct  sigaction {
        union __sigaction_u __sigaction_u;  /* signal handler */
    sigset_t sa_mask;               /* signal mask to apply */
        int     sa_flags;               /* see signal options below */
};

struct definition from nix:

    #[cfg(any(target_os = "macos", target_os = "ios"))]
    #[repr(C)]
    #[allow(missing_copy_implementations)]
    pub struct sigaction {
        pub sa_handler: extern fn(libc::c_int),
        sa_tramp: *mut libc::c_void,
        pub sa_mask: sigset_t,
        pub sa_flags: SockFlag,
    }

So it seems that nix defines sigaction according to private kernel-user boundary OS X struct instead of public struct which actually used as param type to sigaction function.
Also I need the sa_sigaction(instead of sa_handler which is currently used in nix struct) handler to obtain siginfo_t structure and I'm struggling to define c-union in Rust. Any suggestions?

Intermittent failure in test_unistd::test_wait

I see occasional failures in test_unistd::test_wait if I run cargo test over and over:

failures:

---- test_unistd::test_wait stdout ----
    thread 'test_unistd::test_wait' panicked at 'assertion failed: `(left == right)` (left: `Ok(Exited(14028))`, right: `Ok(Exited(14031))`)', test/test_unistd.rs:41


---- test_unistd::test_execve stdout ----
    thread 'test_unistd::test_execve' panicked at 'called `Result::unwrap()` on an `Err` value: Sys(ECHILD)', /home/rustbuild/src/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libcore/result.rs:729



failures:
    test_unistd::test_execve
    test_unistd::test_wait

test result: FAILED. 21 passed; 2 failed; 0 ignored; 0 measured

Linux-only features in nix

I just started working on Netlink sockets support for rust.
Do you think adding support for Netlink (only available on linux) is in scope of the project, or it would better to create a separate library reusing parts of Nix?

Remove nix's Fd in favor of re-exporting std::os::unix::Fd.

Open to adding gettid?

Seeing that pthreads is out of nix's scope, could you add linux's gettid system call so that individual threads can be interacted with. At present, system calls can only operate on entire processes as a whole.

Implementing it strait forward since the system call, like getpid, takes no argument. (imo, It's even easier if you're willing to add the syscall crate as a dependency to abstract away architectural differences, but the crate uses no_std).

Side note: Thank you for this crate! I was in the middle of re-implementing it before it caught my eye. Very well made.

Rationale behind `Errno::clear()` being unsafe?

Was wondering about this. It ought to be safe as it's thread local.

Unexpected ENOTTY in sys::test_termios::test_tcgetattr

I occasionally see this failure if I run cargo test over and over:

failures:

---- sys::test_termios::test_tcgetattr stdout ----
    thread 'sys::test_termios::test_tcgetattr' panicked at 'assertion failed: `(left == right)` (left: `Some(Sys(ENOTTY))`, right: `Some(Sys(EBADF))`)', test/sys/test_termios.rs:15



failures:
    sys::test_termios::test_tcgetattr

test result: FAILED. 22 passed; 1 failed; 0 ignored; 0 measured

thread '<main>' panicked at 'Some tests failed', /home/rustbuild/src/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libtest/lib.rs:255

Get nix compiling on rust beta

Blocked on rust-lang/cargo#1478

Rename project to avoid confusion with Nix.

While I don't mind "*nix" to denote Unix (and Unix-like) systems, "Nix" specifically is taken by the "purely functional package manager".
This could get worse in the future, because of how cargo fits almost perfectly with the Nix model, and I have seen integration prototypes already.
You might have to deal with crates.io packages that interact with Nix, or even fully reimplement it in Rust.

I know it doesn't sound as cool, but what about "posix.rs" or some variation thereof?

Add AF_BLUETOOTH and associated socket bits

Bluetooth (at least on Linux) works over regular old boring sockets with a AF_BLUETOOTH socket type and various BTPROTO_FOO flags.

I'd like to have access to these, and it seems sensible to have them in nix.

Improve nix::Error Debug implementation

It should end up calling Errno::desc()