refactor liblibc into finer-grained crates

[aturon]

The libc crate currently provides a large set of bindings to C APIs. Some of these are cross-platform. But the crate also exports a large number of platform-specific APIs.

It was initially carefully organized according to various standards, but over time it has become a dumping ground for bindings.

As part of the runtime removal RFC we would like to refactor the crate into smaller pieces:

• liblibc should provide fully cross-platform C APIs. This should roughly correspond to the export list currently at the top of liblibc/lib.rs, and encompasses universal C bindings.
• libunix should provide APIs that are available for any #[cfg(unix)] platform.
• libwindows should provide APIs that are available for any #[cfg(windows)] platform.

Ultimately, we are likely to add additional crates like liblinux to provide even more specific sets of bindings.

Due to the top-level exports in liblibc, it should be possible to do this refactoring without overly painful breakage.

[aturon]

cc @alexcrichton @brson

[aturon]

If you're interested in taking this on, please leave a comment on this issue so we can coordinate work with other ongoing changes to the libraries.

[retep998]

I'd personally prefer to split it based on whether it is part of the C standard, part of POSIX, or part of WinAPI. On Windows there are many windows-specific versions of the posix functions, so it seems like a better idea to keep them in libposix.

[aturon]

It's also worth considering automating the generation of these bindings as part of this refactoring.

[retep998]

As part of this refactoring, in many crates there are definitions for winapi/posix things and they should be moved into these crates. I'd opt for these crates to be universal crates containing bindings to everything rather than just what is used in rustc.

[thestinger]

Portability across different C standard library implementations is unrealistic if it's not auto-generated. It can't be split as suggested in the issue if it's done sanely. It should all be auto-generated from the headers with no Rust-specific design or organization involved.

[mahkoh]

I've written posix bindings for x86_64 and x86 linux before and I've generated the structures for x86 with a program (see the posgen directory.)

I strongly advice you to do the same here (but with a much older glibc.) Those structures can be very hard to wrap and I wouldn't expect hand-wrapped structures to be correct.

[sinistersnare]

why not something like liblic and libplatform for platform specific C bindings?

[thestinger]

@sinistersnare: Rust-specific organization means it can't be auto-generated from headers. It will involve a lot of design / organization work and it will always be non-portable and missing functionality. Any proposal involving organization not there on the C end is a bad one.

[Ericson2314]

I also think auto generating bindings is an excellent idea as i rather get link errors in rust land. Splitting C bindings by standard, and additional having kernel-specific libs strikes me as a good idea.

@thestinger do you think these goals are compatible?

[retep998]

How are we going to re-export things in liblibc when liblibc provides the base definitions that other libraries like libwindows will need? Surely we can't have cyclical crate dependencies?

[aturon]

@retep998 I'm not sure I follow the question. Which re-exports do you have in mind? The idea here was just that liblibc would export the cross-platform subset of things it exports today, and other crates could build on that. But as @thestinger points out, any organization not present in the header files will make it harder/impossible to automate binding generation.

[retep998]

@aturon So what you propose is that libwindows contains everything that can be used on Windows, including primitives such as c_ulong, and then liblibc re-exports the cross platform stuff?