From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BLR6H-0002lS-GI for qemu-devel@nongnu.org; Wed, 05 May 2004 14:26:33 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BLR5l-0002V5-Jn for qemu-devel@nongnu.org; Wed, 05 May 2004 14:26:32 -0400 Received: from [193.252.22.26] (helo=mwinf0504.wanadoo.fr) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BLR5l-0002UY-4W for qemu-devel@nongnu.org; Wed, 05 May 2004 14:26:01 -0400 Received: from bellard.org (ATuileries-112-1-2-164.w80-14.abo.wanadoo.fr [80.14.188.164]) by mwinf0504.wanadoo.fr (SMTP Server) with ESMTP id 4837210012C5 for ; Wed, 5 May 2004 20:25:56 +0200 (CEST) Message-ID: <40993237.7050300@bellard.org> Date: Wed, 05 May 2004 20:28:07 +0200 From: Fabrice Bellard MIME-Version: 1.0 Subject: Re: [Qemu-devel] Stuff. References: <1083706269.26125.1150.camel@imladris.demon.co.uk> In-Reply-To: <1083706269.26125.1150.camel@imladris.demon.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org David Woodhouse wrote: > Has anyone considered the possibility of emulating libc, rather than > emulating system calls? That's what em86 used to do for emulating i386 > code on Alpha -- rather than letting it run a 'real' non-native libc and > then emulating only syscalls. > > I appreciate that syscalls are a far more stable ABI to be emulating, > and there are far fewer structures to convert -- but wouldn't it be > faster to emulate the library itself? Especially if we can extend that > to emulate libX11 too :) Emulating libc would be _very_ difficult (there are thousands of calls to convert). There were provisions in em86 to do that, but it was never really used. Moreover, I think the speed up would be small compared to the complexity of the task. > It's cute that I have i386 acroread running in a Mozilla window through > mozplugger. It'd be cuter if I could get Mozilla plugins running in the > _same_ process, rather than in a separate process. > > > ---- > > Also, why do we do what we do in linux-user/path.c? What does it give us > that couldn't be achieved by stat("$prefix/$filename") in a trivial > path() function? Other than taking for ever to start up when > /usr/gnemul/i386-linux is actually an nfs-mounted root file system from > elsewhere. (When I say forever I mean that literally. We keep following > symlinks recursively). The goal was to avoid making too many syscalls. Fabrice.