Re: Using unistd functions vs calling syscall straight in the code

[Murali Vijayaraghavan <vmurali@csail.mit.edu>]

[-- Attachment #1: Type: text/plain, Size: 2349 bytes --]

On Fri, Aug 10, 2012 at 11:59 PM, Szabolcs Nagy <nsz@port70.net> wrote:

> * 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
>

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.

[-- Attachment #2: Type: text/html, Size: 3089 bytes --]