add support for mknodat

[Mic92]

No description provided.

[asomers]

Better to reference POSIX docs than Linux docs
http://pubs.opengroup.org/onlinepubs/9699919799/functions/mknod.html

[Mic92]

The POSIX one is not super helpful for end-users. I would rather include no manpage link, then link to the posix one (example: http://man7.org/linux/man-pages/man2/mknodat.2.html#NOTES)

[asomers]

nix is a portable crate, not a Linux crate. The Linux manpage is only useful for Linux users. But the POSIX man page can be relied upon by all nix users.

[Mic92]

But POSIX deviate from reality in subtle ways (hence the use of shall all over the place). Nix is not fully portable anyway, since it only provides a thin layer above systems libc unlike projects like gnulib. So you have to actually look at every manpage of every operating system you care about to be sure, it won't break.

[Mic92]

This would be actually be the more honest documentation: https://www.gnu.org/software/gnulib/manual/gnulib.html#mknodat

[asomers]

That's irrelevant, because nix doesn't bind to gnulib; it binds to the system's C library. The POSIX documentation is the GCD of all supported platforms. While some platforms may deviate, the POSIX docs are still the single most relevant source.

[asomers]

Thanks for changing the man page link. Next, could you try to add a test for mknod and mknodat? Perhaps creating a fifo and then stating it?

[Susurrus]

We would like to write tests/examples for all additions to nix if possible. While having tests that don't require root would be ideal, I think having an example in a doc test that isn't run and a test that requires root would be sufficient coverage.

[Mic92]

I already added the test for FIFO.

[Susurrus]

I just read up on mknodat and it follows the common theme for many POSIX APIs where there are 2 function arguments that are really 3 separate states and not all combinations of these variables are valid. For example, if pathname is absolute, dirfd is ignored. I think we should use an enum type here to encapsulate these 3 types instead of continuing to allow some partially-valid types. Instead of dirfd and path, I'd like just path which is an enum with AbsPath(&P), RelCurDir(&P), and RelTo(&P, &RawFd) or something like that. I think there was a previous issue where I suggested this approach as well, but I can't find it now. The only issue here is where/if we should verify the path is absolute or relative in the code to generate those enum types. But since this is a convention that pops up a lot, I'd like us to have a good API for working with it.

@asomers Any thoughts on this?

[Mic92]

Hi, sorry but I have no time on polishing the API further.
If you think you want to this feature, just do:

git push [email protected]:Mic92/nix mknodat

(force-push is also possible just in case).

[Mic92]

I close this pull request in case I block somebody else who wants to implement this feature.
Feel free to pick whatever you think is necessary. I also implement some other features like setrlimit/getrlimit or transparent large file support on this branch: https://github.com/Mic92/nix/commits/cntrfs

• xattr functions can be found here: https://github.com/Mic92/cntr/blob/master/src/xattr.rs
• fstatvfs: https://github.com/Mic92/cntr/blob/master/src/statvfs.rs