Add SEEK_DATA/SEEK_HOLE constants

[posborne]

Relates to nix-rust/nix#377. These constants
are only available in systems running the Linux kernel.

[rust-highfive]

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

Thanks! Looks like these constants may not exist yet on musl though?

[posborne]

Thanks! Looks like these constants may not exist yet on musl though?

Yes, that would appear to be the case. Wasn't sure, so I figured I would let CI let me know. I'll add an ignore in the tests for that constant for musl (I believe that is the best way to handle).

[alexcrichton]

Ah the preferred method is actually to duplicate these constants down to the level where they're defined (e.g. android + non-musl linux) rather than #[cfg(not(..))] but other than that sounds good to me.

[posborne]

Ah the preferred method is actually to duplicate these constants down to the level where they're defined (e.g. android + non-musl linux) rather than #[cfg(not(..))] but other than that sounds good to me.

I can do this, although it doesn't seem strictly necessary (or beneficial) and makes usage of the constants in downstream crates more complicated as instead of worrying about the OS we need to be concerned with the libc implementation (which is fine in some cases, but unnecessary here). These constants are defined by the kernel and musl lets the kernel accept/reject the values for calls where they are used (e.g. lseek).

[alexcrichton]

Ah yeah we just typically try to stick to the musl headers, regardless of whether they just forward it to the kernel or not

[posborne]

Sure, I'll take a look at fixing musl as well then.

[posborne]

Ok, Travis is happy after amending the commit to have the constants live under unix/notbsd/linux/other

[alexcrichton]

@bors: r+ 45448fb

[bors]

⌛ Testing commit 45448fb with merge 1e2d77a...

[bors]

☀️ Test successful - status-appveyor, travis