Refactoring the Linux module: first try.

[GuillaumeLestringant]

So this is a first try of the refactoring proposed in #371. It sets the tree structure up, and gives a go at the fcntl.h header. It is an interesting choice because it has type and structure definitions, generic and platform specific macros, and also POSIX and Linux specific definitions, as well as glibc and musl specific ones. So it covers more or less all possible cases.

For clarity’s sake, all definitions of this header have been placed at the end of their respective sections, along with a comment saying:

/* Header <fcntl.h> */

Doing so with all headers should make sure that a specific definition is easier to find than in the mess we have for now.

A few notes on unexpected issues.

• Generally speaking, glibc and uclibc are closer together than with musl. So, for definitions found in glibc but neither musl nor uclibc, I created a gnu submodule under other (and a uclibc one, that remains empty for now).
• The glibc has a structure named file_handle whose last element is a zero-sized array. This is rendered by a dynamically-sized array in Rust, but then, the struct cannot implement the Copy trait, and makes the s! macro bug. I commented that line out, but a better solution would be wished.
• I use a feature file_offset64 that should be equivalent to __USE_FILE_OFFSET64. This feature must be defined in musl targets (!), but I don’t know how to make sure it is the case. As a palliative, I added the condition target_env = "musl" everywhere file_offset64 is used, but this cannot be definitive. Advice strongly wished here.

PS: I can’t test every platform at home, so there might be some remaining bugs. Will add some commits when I know where they are.

[rust-highfive]

r? @alexcrichton

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

[petrochenkov]

I haven't looked carefully, but "reuse more code" and "+760 −316" diff look a bit contradicting, no? Is some new stuff added?

[GuillaumeLestringant]

Yes, there is indeed some added stuff. And a part of it are comments.

[GuillaumeLestringant]

So, I finally managed to put most of the bugs out. There are only three remaining, for which I have no clue. So, asking for help.

On i686-unknown-linux-musl (job 9), the test script doesn’t find the flock type, although it is undoubtedly defined in common/b32/x86.rs. Is there something weird going on with the cfg_if macro? Am I missing something?

On aarch64-unknown-linux-gnu (job 11), 5 macros seem not to be defined in the library against which the tests are done. These macros are defined here and here, each time gated by a __USE_GNU macro, so I don’t get it why the AArch64 version doesn’t have them.

On mipsel-unknown-linux-musl (job 17), if I understand the error messages correctly, the script complains about struct flock having no l_sysid field, but the musl definition has no such field: only the glibc definition has it (and uClibc too).

I don’t really understand how the tests are done so, maybe I’m missing something, or maybe the tests are wrong somehow, I don’t know. I would really use some insight here.

[alexcrichton]

Thanks for the PR @GuillaumeLestringant!

Before going much farther, though, I think we may want to get on the same page about the motivation of this refactoring. Could you help walk me through what you're thinking?

Today this crate optimizes for readability rather than writing new bindings themselves. That is, we greatly favor duplication over a jungle of #[cfg]. Additionally this crate favors simple-as-possible bindings, avoiding comments/organization/otherwise. These aspects mean that working within one particular platform is almost always a breeze as there's a "path to the root" in the module hierarchy where you just pick up more bindings as you go along. Additionally when binding a new platform, you frequently just start fresh in a new module and add in everything until it starts compiling.

Finally, the duplication is all validated through the CI infrastructure on this repository. That is, basically all definitions/constants/functions are automatically verified, so there's no risk of duplication silently introducing bugs.

So given all that, could you walk me through the high level goals and rationale of this refactor? Additionally, I'm curious where this'll all end up eventually!

[bors]

☔ The latest upstream changes (presumably #377) made this pull request unmergeable. Please resolve the merge conflicts.