On Fri, Aug 10, 2012 at 11:16 PM, Szabolcs Nagy
<nsz@port70.net> wrote:
* Murali Vijayaraghavan <vmurali@csail.mit.edu> [2012-08-10 21:47:59 +0900]:
> You guys do have a unistd implementation which supposedly implements each
> of the system calls. But you are not consistent with the use of these
> functions to perform the unistd-implemented tasks. Wouldn't it be a lot
> cleaner to call these functions instead of calling syscall / syscall_cp
> directly from the other (top-level) functions? Was there some rationale or
> is it just code evolution?
>
i don't understand the question
can you show with an example what do you mean?
calling a libc function is not the same as using a linux
syscall, and there is usually a reason why one is used
instead of the other..
(the first has posix semantics the second has whatever
semantics linux have, even if these happen to be compatible
then the first one creates an extra call and an extra
internal dependency when static linking is used)
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?
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 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.