From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1503 Path: news.gmane.org!not-for-mail From: Murali Vijayaraghavan Newsgroups: gmane.linux.lib.musl.general Subject: Re: Using unistd functions vs calling syscall straight in the code Date: Sat, 11 Aug 2012 00:40:25 +0900 Message-ID: References: <20120810141613.GA20243@port70.net> <20120810145923.GB20243@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=bcaec53d5ed7a7760004c6eb29d5 X-Trace: dough.gmane.org 1344613245 23045 80.91.229.3 (10 Aug 2012 15:40:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 10 Aug 2012 15:40:45 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1504-gllmg-musl=m.gmane.org@lists.openwall.com Fri Aug 10 17:40:45 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1SzrKK-00046u-2i for gllmg-musl@plane.gmane.org; Fri, 10 Aug 2012 17:40:40 +0200 Original-Received: (qmail 28091 invoked by uid 550); 10 Aug 2012 15:40:38 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 28079 invoked from network); 10 Aug 2012 15:40:38 -0000 In-Reply-To: <20120810145923.GB20243@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:1503 Archived-At: --bcaec53d5ed7a7760004c6eb29d5 Content-Type: text/plain; charset=ISO-8859-1 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. --bcaec53d5ed7a7760004c6eb29d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Aug 10, 2012 at 11:59 PM, Szabol= cs Nagy <nsz@port70.net> wrote:
* Murali Vijayaraghavan <vmural= i@csail.mit.edu> [2012-08-10 23:32:11 +0900]:
> For example, I could have implemented src/stdio/__st= dio_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 unist= d is
> the POSIX compatibility layer (correct me if I am wrong). So shouldn&#= 39;t the
> C standard library, namely stdio functions like scanf eventually use t= he
> 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.=A0

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

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 tha= t way - I
> can get the function type simply by decoding the instruction rather th= an
> 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 supp= ose I can do this. I was just more familiar with unistd functions' sema= ntics than the syscall API's. But moving forward, this is more maintain= able.=A0Thanks.
--bcaec53d5ed7a7760004c6eb29d5--