TheAlmostGenius wrote:
ANSI C is a library that makes no massive assumptions and can easily be ported between x86 and x86_64 using preprocessor directives. POSIX was a separate C standard that makes more assumptions and requires more kernel support. ANSI is used to write the first parts of the system in C and add the POSIX compatibility into the kernel as extra real syscalls
That's not how it works in practice. POSIX tends to be lower level than the standard C library. So usually a *nix kernel implements the syscalls required for the POSIX interfaces and the function of the C standard library are implemented on top of this (e.g. fread() from stdio.h will call POSIX read() for the actual reading and just implement some buffering mechanism in addition).
Quote:
So wouldn't adding the calls for POSIX basically make my kernel another *nix clone anyway considering it was basically designed around *nix style OSes.
Yes, if your kernel interface is made for POSIX, I'd call it a *nix.
What you can try to do is creating your own native API that looks how you want it to look and then implementing POSIX on top of that, as something like a compatibility layer, which just implements POSIX functions as wrappers around your native interface. If you want to do this, though, be aware that POSIX contains a few concepts that are quite hard to map to different concepts. One of them is the separation of fork/exec, which allows running some code between them, and the whole file descriptor inheritance model. It's a powerful concept, but also one that takes a big influence on your design.