On Fri, Aug 10, 2012 at 11:16 PM, Szabolcs Nagy wrote: > * Murali Vijayaraghavan [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.