* Murali Vijayaraghavan <vmurali@csail.mit.edu> [2012-08-10 23:32:11 +0900]:

> For example, I could have implemented src/stdio/__stdio_read.c using
> src/unistd/readv.c's readv function instead of calling
> syscall/syscall_cp(SYS_readv, ...) in lines 20 and 24. I believe unistd is
> the POSIX compatibility layer (correct me if I am wrong). So shouldn't the
> C standard library, namely stdio functions like scanf eventually use the
> unistd functions instead of using the syscall directly?
>

that's not how it works,

unistd is no more posix than stdio
they are all part of the posix api

stdio functions are also defined by the
c standard so in this sense it's good
that the stdio implementation does not
depend on the larger posix api
(it only depends on the syscall api)

but yes otherwise stdio could use unistd
functions and then it would be a bit
slower (+1 call) and +1 symbol resolution
during linking i guess

> This would have made my job easier because I could have just modified this
> POSIX compability layer instead of scanning through the C standard library
> functions and changing them one by one. Remember I have multiple special

you are not supposed to change the functions

you only need to implement the syscalls
and dummy out the ones you don't use
(ie. have a large switch, with a defalut: return -ENOSYS;)

if you modify the .c source files you are
doing it wrong

> instructions to perform each IO task instead of a single system call
> instruction, since it's easier to implement hardware simulator that way - I
> can get the function type simply by decoding the instruction rather than
> reading some register.

even if you have special instructions
in your emulator i don't see why you
cannot implement the syscall api
(actually that seems simpler and more
correct to me than putting random special
instructions all over the place)