Re: [Qemu-devel] [PATCH, RFC] BSD user emulator

[M. Warner Losh]

In message: <address@hidden>
            Alexander Graf <address@hidden> writes:
: 
: 
: 
: 
: Am 01.09.2008 um 18:25 schrieb "M. Warner Losh" <address@hidden>:
: 
: > In message: <address@hidden>
: >            Alexander Graf <address@hidden> writes:
: > :
: > : On Aug 30, 2008, at 10:31 AM, Blue Swirl wrote:
: > :
: > : > Hi,
: > : >
: > : > This version can actually execute some programs, for example:
: > : >
: > : > ./sparc64-bsd-user/qemu-sparc64 -d in_asm /bin/cat /etc/motd
: > : > OpenBSD 4.4 (GENERIC) #1715: Mon Aug 11 17:55:10 MDT 2008
: > : >
: > : > Welcome to OpenBSD: The proactively secure Unix-like operating  
: > system.
: > : >
: > : > Please use the sendbug(1) utility to report bugs in the system.
: > : > Before reporting a bug, please try to reproduce it with the latest
: > : > version of the code.  With bug reports, please try to ensure that
: > : > enough information to reproduce the problem is enclosed, and if a
: > : > known fix for it exists, include that as well.
: > : >
: > : > Something is not correct with errno handling, it could also be a  
: > bug
: > : > in CPU emulation:
: > : > /sparc64-bsd-user/qemu-sparc64 -d in_asm /bin/cat /foobar
: > : > cat: /foobar: Undefined error: 0
: > : >
: > : > Some other programs just fail:
: > : > ./sparc64-bsd-user/qemu-sparc64 -d in_asm /bin/ls
: > : > ls: Cannot allocate memory
: > : > ./sparc64-bsd-user/qemu-sparc64 -d in_asm /bin/ksh
: > : > ksh in malloc(): error: chunk overflow
: > : > ./sparc64-bsd-user/qemu-sparc64 -d in_asm /usr/bin/id
: > : > Segmentation fault
: > : > ./sparc64-bsd-user/qemu-sparc64 -d in_asm /sbin/ifconfig
: > : > lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 0¸
: > : > ifconfig: getifgroups: Cannot allocate memory
: > : >
: > : > I've cleaned up the patch a bit. Signals, ioctls and structure
: > : > conversions are still unimplemented and as usual, no docs.
: > : >
: > : > I think this is getting ready to be committed pretty soon. Any
: > : > comments, objections?
: > :
: > : Just off the top of my head: Shouldn't BSD userspace and Darwin
: > : userspace emulation be able to share a good bunch of syscalls?
: > : IIRC the positive Darwin syscalls should be some recent FreeBSD
: > : syscalls that should look pretty similar to OpenBSD syscalls. I  
: > might
: > : be totally wrong here though ;-).
: >
: > Kinda.
: >
: > The system calls are mostly similar between the BSDs, but do vary for
: > syscalls added since 4.4BSD Lite-2.
: >
: 
: So darwin and all bsds could share most 4.4 bsd syscalls and implement  
: the others depending on their specific target? Sounds like a big win  
: to me.
: 
: Too bad fabrice doesn't agree to this.

Well, it isn't quite *that* simple.  If you look at the syscall lists,
you'll see they are mostly in common.  However, theres been some
divergence so you'll need multiple tables, one for each BSD.  Maybe
90-95% of each of them will be the same.

I've not specifically looked at Darwin system calls, but NetBSD did a
Darwin emulator without a lot of hassle.  They had to do a lot for
Mach-O image activation, of course, and fill in a number of missing
system calls.

I think that Fabrice likely will see the light when the tangible
benefits are shown.  He's likely worried about the same problem that
the FreeBSD Linux ABI implementation suffered from: lots of special
cases because Linux returns this error rather than that error, or
treats group wheel differently in this case or that, etc.  These
problems have been mostly solved in the FreeBSD implementation in the
kernel by having the emulation layers use a common set of core kernel
routines to implement things, arranging for the right set of flags and
such to be passed down.

Anyway, that's just my two cents and speculation...  Others, including
those speculated about, may differ...  Objects in the mirror are
closer than they appear...  If mail reader catches fire, leave the
room and call for help...

Warner