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

[Blue Swirl]

On 9/1/08, M. Warner Losh <address@hidden> wrote:
> 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...

Time for some statistics:

grep 'SYS_[a-z_]' fbsd-syscall.h |sed 's/[    ][      ]*/ /g'|sort -k
3 -n >fbsd-syscalls
grep 'SYS_[a-z_]' nbsd-syscall.h |sed 's/[    ][      ]*/ /g'|sort -k
2 -n >nbsd-syscalls
grep 'SYS_[a-z_]' obsd-syscall.h |sed 's/[    ][      ]*/ /g'|sort -k
3 -n >obsd-syscalls

wc -l *bsd-syscalls
  365 fbsd-syscalls
  366 nbsd-syscalls
  187 obsd-syscalls
  918 total

diff -u nbsd-syscalls fbsd-syscalls |diffstat
 fbsd-syscalls |  475 ++++++++++++++++++++++++++++------------------------------
 1 file changed, 237 insertions(+), 238 deletions(-)

diff -u obsd-syscalls fbsd-syscalls |diffstat
 fbsd-syscalls |  298 ++++++++++++++++++++++++++++++++++++++++++++++------------
 1 file changed, 238 insertions(+), 60 deletions(-)

diff -u obsd-syscalls nbsd-syscalls |diffstat
 nbsd-syscalls |  297 ++++++++++++++++++++++++++++++++++++++++++++++------------
 1 file changed, 238 insertions(+), 59 deletions(-)

Some are just renames, but those are still large numbers. I have to
add syscall number conversion tables, I thought host SYS_xx were
almost always equal to target SYS_xx.