From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1499 Path: news.gmane.org!not-for-mail From: Murali Vijayaraghavan Newsgroups: gmane.linux.lib.musl.general Subject: Using unistd functions vs calling syscall straight in the code Date: Fri, 10 Aug 2012 21:47:59 +0900 Message-ID: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=0016e6d6446dfcfdab04c6e8c0f1 X-Trace: dough.gmane.org 1344602903 30891 80.91.229.3 (10 Aug 2012 12:48:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 10 Aug 2012 12:48:23 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1500-gllmg-musl=m.gmane.org@lists.openwall.com Fri Aug 10 14:48:22 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 1SzodS-0006cp-2r for gllmg-musl@plane.gmane.org; Fri, 10 Aug 2012 14:48:14 +0200 Original-Received: (qmail 24086 invoked by uid 550); 10 Aug 2012 12:48:12 -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 24077 invoked from network); 10 Aug 2012 12:48:12 -0000 Xref: news.gmane.org gmane.linux.lib.musl.general:1499 Archived-At: --0016e6d6446dfcfdab04c6e8c0f1 Content-Type: text/plain; charset=ISO-8859-1 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 --0016e6d6446dfcfdab04c6e8c0f1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi

I am trying to run C programs on a barebones (MIPS-li= ke) processor simulator without any OS. The simulator mainly implements the= userspace ISA, with no syscall instruction support in hardware. I was hopi= ng 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 functio= ns like read and write should be calling these custom instructions in assem= bly, 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 on= e whose structure I could understand well, making it easy to port. I did su= ccessfully and easily port it for my purposes, which brings to my question/= comment.

You guys do have a unistd implementation which supposed= ly 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 r= ationale or is it just code evolution?

Thanks
Murali


--0016e6d6446dfcfdab04c6e8c0f1--