On Fri, Aug 10, 2012 at 11:59 PM, Szabolcs Nagy wrote: > * Murali Vijayaraghavan [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 > Oh k. I thought one was on top of the other. If they are all supposed to be part of POSIX, I guess it makes more sense to avoid an extra call. > > > 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) > I suppose I can do this. I was just more familiar with unistd functions' semantics than the syscall API's. But moving forward, this is more maintainable. Thanks.