Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use definitions from libc instead of writing our own #264

Closed
kamalmarhubi opened this issue Feb 12, 2016 · 6 comments
Closed

Use definitions from libc instead of writing our own #264

kamalmarhubi opened this issue Feb 12, 2016 · 6 comments

Comments

@kamalmarhubi
Copy link
Member

No description provided.

@kamalmarhubi
Copy link
Member Author

I'm going to start going through module by module over the next week or so.

@kamalmarhubi kamalmarhubi self-assigned this Feb 12, 2016
@kamalmarhubi
Copy link
Member Author

Thinking about this a bit more, we may want our own analog of the sys module pattern. Right now it's hard to track down where items come in because the cfg attrs are all over the place. @arcnmx you have a recently opened RFC on a related topic. Thoughts?

@kamalmarhubi
Copy link
Member Author

Ah, discussion of conditional compilation module pattern would belong in #98.

homu added a commit that referenced this issue Feb 28, 2016
Add introduction/constants/enumeration/uninitialized to CONVENTIONS.

I have added new sections to the file. I would like the usual suspects to read them critically and offer critique.

When have agreed to add certain versions I will add Issues to track our progress in getting the code to follow the conventions. For two of the sections they already exist in #254 and #264.
homu added a commit that referenced this issue Feb 29, 2016
Use libc constants in sys/signal.rs.

Work toward #264.
kamalmarhubi added a commit to kamalmarhubi/nix-rust that referenced this issue Mar 5, 2016
kamalmarhubi added a commit to kamalmarhubi/nix-rust that referenced this issue Mar 5, 2016
homu added a commit that referenced this issue Mar 5, 2016
unistd: Use bindings from libc instead of our own

Refs #264
kamalmarhubi added a commit to kamalmarhubi/nix-rust that referenced this issue Mar 6, 2016
kamalmarhubi added a commit to kamalmarhubi/nix-rust that referenced this issue Mar 6, 2016
homu added a commit that referenced this issue Mar 6, 2016
unistd: Use bindings from libc instead of our own

Refs #264
@kamalmarhubi
Copy link
Member Author

Mentored bug

This is something the maintainers will be working on on and off, but it will take some time. It's a good place to start, and I'm happy to help anyone who wants to contribute patches towards it.

The intention is to remove all extern declarations from nix, and rely on them from the libc crate instead.

This can be done a module at a time. In some cases, functions declared in nix are not yet in libc, so this may require some patches to libc. I've made a few PRs there, and have a good idea of where things belong, so I can help with those PRs as well.

Example PR doing this for the unistd module: #294

@kamalmarhubi
Copy link
Member Author

The basic steps for a PR would be:

  1. remove the ffi submodule
  2. replace references to ffi::foo by libc::foo
    • if libc::foo is missing, create a PR on the libc crate to add it
  3. make sure to run the tests (cargo test)
  4. open the PR!

kamalmarhubi added a commit to kamalmarhubi/nix-rust that referenced this issue Mar 10, 2016
homu added a commit that referenced this issue Mar 10, 2016
uio: Use bindings from libc instead of our own

Refs #264
kamalmarhubi added a commit to kamalmarhubi/nix-rust that referenced this issue Mar 15, 2016
We define many bitflags types with values from the libc crate. Currently
these look like this:

    bitflags!{
        flags ProtFlags: libc::c_int {
            const PROT_NONE      = libc::PROT_NONE,
            const PROT_READ      = libc::PROT_READ,
            const PROT_WRITE     = libc::PROT_WRITE,
            const PROT_EXEC      = libc::PROT_EXEC,
            #[cfg(any(target_os = "linux", target_os = "android"))]
            const PROT_GROWSDOWN = libc::PROT_GROWSDOWN,
            #[cfg(any(target_os = "linux", target_os = "android"))]
            const PROT_GROWSUP   = libc::PROT_GROWSUP,
        }
    }

There's some repetition which is tedious. With the new macro, the above
can instead be written

    libc_bitflags!{
        flags ProtFlags: libc::c_int {
            PROT_NONE,
            PROT_READ,
            PROT_WRITE,
            PROT_EXEC,
            #[cfg(any(target_os = "linux", target_os = "android"))]
            PROT_GROWSDOWN,
            #[cfg(any(target_os = "linux", target_os = "android"))]
            PROT_GROWSUP,
        }
    }

Thanks to Daniel Keep for the Little Book of Rust Macros, and for
helping with this macro.

Refs nix-rust#264
kamalmarhubi added a commit to kamalmarhubi/nix-rust that referenced this issue Mar 16, 2016
We define many bitflags types with values from the libc crate. Currently
these look like this:

    bitflags!{
        flags ProtFlags: libc::c_int {
            const PROT_NONE      = libc::PROT_NONE,
            const PROT_READ      = libc::PROT_READ,
            const PROT_WRITE     = libc::PROT_WRITE,
            const PROT_EXEC      = libc::PROT_EXEC,
            #[cfg(any(target_os = "linux", target_os = "android"))]
            const PROT_GROWSDOWN = libc::PROT_GROWSDOWN,
            #[cfg(any(target_os = "linux", target_os = "android"))]
            const PROT_GROWSUP   = libc::PROT_GROWSUP,
        }
    }

There's some repetition which is tedious. With the new macro, the above
can instead be written

    libc_bitflags!{
        flags ProtFlags: libc::c_int {
            PROT_NONE,
            PROT_READ,
            PROT_WRITE,
            PROT_EXEC,
            #[cfg(any(target_os = "linux", target_os = "android"))]
            PROT_GROWSDOWN,
            #[cfg(any(target_os = "linux", target_os = "android"))]
            PROT_GROWSUP,
        }
    }

Thanks to Daniel Keep for the Little Book of Rust Macros, and for
helping with this macro.

Refs nix-rust#264
homu added a commit that referenced this issue Mar 16, 2016
Add libc_bitflags convenience macro

We define many bitflags types with values from the libc crate. Currently
these look like this:

    bitflags!{
        flags ProtFlags: libc::c_int {
            const PROT_NONE      = libc::PROT_NONE,
            const PROT_READ      = libc::PROT_READ,
            const PROT_WRITE     = libc::PROT_WRITE,
            const PROT_EXEC      = libc::PROT_EXEC,
            #[cfg(any(target_os = "linux", target_os = "android"))]
            const PROT_GROWSDOWN = libc::PROT_GROWSDOWN,
            #[cfg(any(target_os = "linux", target_os = "android"))]
            const PROT_GROWSUP   = libc::PROT_GROWSUP,
        }
    }

There's some repetition which is tedious. With the new macro, the above
can instead be written

    libc_bitflags!{
        flags ProtFlags: libc::c_int {
            PROT_NONE,
            PROT_READ,
            PROT_WRITE,
            PROT_EXEC,
            #[cfg(any(target_os = "linux", target_os = "android"))]
            PROT_GROWSDOWN,
            #[cfg(any(target_os = "linux", target_os = "android"))]
            PROT_GROWSUP,
        }
    }

Thanks to Daniel Keep for the Little Book of Rust Macros, and for
helping with this macro.

Refs #264
homu added a commit that referenced this issue Mar 16, 2016
Add libc_bitflags convenience macro

We define many bitflags types with values from the libc crate. Currently
these look like this:

    bitflags!{
        flags ProtFlags: libc::c_int {
            const PROT_NONE      = libc::PROT_NONE,
            const PROT_READ      = libc::PROT_READ,
            const PROT_WRITE     = libc::PROT_WRITE,
            const PROT_EXEC      = libc::PROT_EXEC,
            #[cfg(any(target_os = "linux", target_os = "android"))]
            const PROT_GROWSDOWN = libc::PROT_GROWSDOWN,
            #[cfg(any(target_os = "linux", target_os = "android"))]
            const PROT_GROWSUP   = libc::PROT_GROWSUP,
        }
    }

There's some repetition which is tedious. With the new macro, the above
can instead be written

    libc_bitflags!{
        flags ProtFlags: libc::c_int {
            PROT_NONE,
            PROT_READ,
            PROT_WRITE,
            PROT_EXEC,
            #[cfg(any(target_os = "linux", target_os = "android"))]
            PROT_GROWSDOWN,
            #[cfg(any(target_os = "linux", target_os = "android"))]
            PROT_GROWSUP,
        }
    }

Thanks to Daniel Keep for the Little Book of Rust Macros, and for
helping with this macro.

Refs #264
@kamalmarhubi kamalmarhubi removed their assignment Mar 21, 2016
homu added a commit that referenced this issue Apr 17, 2016
mount: Use bindings from libc instead of our own

Ref #264

Changing internal usage of `ffi::mount` and `ffi:umount` to make use of libc.
homu added a commit that referenced this issue Apr 23, 2016
fcntl: Use bindings from libc instead of our own

**Un-finished** and looking for help. As #264 was tagged "mentor, good first bug"

Ref #264

I couldn't find `F_GET_SEALS`, or `F_ADD_SEALS` in libc.

Is this a case where I should be making a PR over there? I'm not sure where exactly to address it in libc.
@Susurrus Susurrus added this to the 1.0 milestone Nov 5, 2017
@Susurrus
Copy link
Contributor

Susurrus commented Nov 5, 2017

Supplanted by #316 and #748.

@Susurrus Susurrus closed this as completed Nov 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants