Description
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.