musl - Using unistd functions vs calling syscall straight in the code

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Fri, 10 Aug 2012 21:47:59 +0900
From: Murali Vijayaraghavan <vmurali@...il.mit.edu>
To: musl@...ts.openwall.com
Subject: Using unistd functions vs calling syscall straight in the code

Hi

I am trying to run C programs on a barebones (MIPS-like) processor
simulator without any OS. The simulator mainly implements the userspace
ISA, with no syscall instruction support in hardware. I was hoping to
instead support some of the system calls (like open, read, write, etc,
mainly for debugging purposes) by using custom instructions, one for each
(or a few similar) system call(s). For that, the implementation of
functions like read and write should be calling these custom instructions
in assembly, in other words, I have to port the system call layer to my
simulator. I looked at musl among other libc implementations, and this was
the only one whose structure I could understand well, making it easy to
port. I did successfully and easily port it for my purposes, which brings
to my question/comment.

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?

Thanks
Murali

Content of type "text/html" skipped

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.