Reorganize the Linux module to reuse more code

[GuillaumeLestringant]

This issue is a follow-up of the discussion started with #368 trying to be more general. The main idea is that the separation between different libc as a first branching inside the Linux module actually leads to much more code duplication as could be possible by branching by platform first, and maybe (we shall see if it is possible) have the libc and the platform be orthogonal.

In this issue, I wish to propose a working plan for this severe refactoring, to get approval before anybody, me included, starts working.

Step 0: the MIPS module

The recently created MIPS and MIPS64 modules are actually MIPS-glibc and MIPS64-glibc. Maybe, to make that clearer, we should put them in their logical place, that is inside other/b32 and other/b64 module. Maybe it will induce too much changes to be worth the effort, so let this be optional.

Step 1: get an appropriate test platform for MIPS(64)

@alexcrichton expressed concern on this matter, and it should be solved before any great amount of work is done. Question: is #369 enough or do we need more?

Step 2: set up the working space

We can than create a common submodule, with its own submodules b32, b64 and every necessary platform, to receive everything that is common to every one of the three libc. This submodule would be included alongside the remaining musl and other and mips(64) modules, to make sure nothing is lost while the work is in progress.

Step3: put in common everything that can be put in common

To make this easier, a few recommendations.

Type definitions

As much as possible, use the C types in the right part of the definition. For instance, clock_t is defined as i32 in mips and other/b32, as i64 in other/b64, and as c_long in musl. These are actually all longs. Using ::c_long for all of them would make it possible to have a single definition for all Linuxes, that would actually be in notbsd given that android has the same definition.

Structure definitions

It might not always be possible, but the apparent discrepancies in definitions between different libc are generally less than they seem. An example is given here.

To make this work, it might be necessary to have some cfg elements to mimic the macros like __USE_FILE_OFFSET64. How exactly would that be possible?

Macros and functions

Apart from a few exceptions, these should really be the same across the different libc and only differ in the platforms.

Step 4: see if libc and platform are orthogonal

That is, make sure that all the definitions remaining in other and musl are platform independent. if this has been achieved, merge common/mod.rs into linux/mod.rs, and have a separate if cfg for platforms and for libc.

Step 5: bonus

See if some of the definitions now in linux/mod.rs can be pulled further up in the tree.

[alexcrichton]

Note that most of the directory structure and hierarchy of this crate is explicitly not optimized for sharing code. Rather it's optimized for readability and clarity of definitions themselves.

In that sense it's totally fine to make copies of entire modules when adding new platforms, it's no skin off our backs!