[Qemu-devel] New Year's starting over ... bsd-user

[Qemu-devel] New Year's starting over ... bsd-user

[Sean Bruno]

[-- Attachment #1: Type: text/plain, Size: 527 bytes --]


I'm pondering where to start with getting FreeBSD's bsd-user code into
shape so it could actually be reviewed and accepted now that its sort of
working again (signal handling fixed finally).

I almost feel like the existing code should be purged, except that it
gives a good history (and this seems lazy to me).

As a first pass, I guess, I'd like to at least make i386 user run on
x86_64.  What would you folks like to see in a first pass?

sean

ref: https://github.com/seanbruno/qemu-bsd-user/tree/bsd-user


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 614 bytes --]

Re: [Qemu-devel] New Year's starting over ... bsd-user

[Sean Bruno]

[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]



On 01/03/17 09:18, Sean Bruno wrote:
> 
> I'm pondering where to start with getting FreeBSD's bsd-user code into
> shape so it could actually be reviewed and accepted now that its sort of
> working again (signal handling fixed finally).
> 
> I almost feel like the existing code should be purged, except that it
> gives a good history (and this seems lazy to me).
> 
> As a first pass, I guess, I'd like to at least make i386 user run on
> x86_64.  What would you folks like to see in a first pass?
> 
> sean
> 
> ref: https://github.com/seanbruno/qemu-bsd-user/tree/bsd-user
> 

Primitive example of what I think I should base my patchset on.  Its
invasive and large.

https://github.com/seanbruno/qemu-bsd-user/tree/merge1

That branch, is all the bsd-user changes that are pending in one large
"splat".  It excludes the new architectures (arm, aarch64, mips, mips64)
that we are actively using.  i386-bsd-user when compiled statically on
x86_64 will run a static (rescue) sh ... so, I think that's good.
x86_64 running on x86_64 just blows up.

As for sparc/sparc64 ... I'm tempted to delete them as nobody in freebsd
is actively maintaining them nor do we have any expectation that they
will work someday.

sean


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [Qemu-devel] New Year's starting over ... bsd-user

[Thomas Huth]

On 03.01.2017 18:11, Sean Bruno wrote:
> 
> 
> On 01/03/17 09:18, Sean Bruno wrote:
>>
>> I'm pondering where to start with getting FreeBSD's bsd-user code into
>> shape so it could actually be reviewed and accepted now that its sort of
>> working again (signal handling fixed finally).
>>
>> I almost feel like the existing code should be purged, except that it
>> gives a good history (and this seems lazy to me).
>>
>> As a first pass, I guess, I'd like to at least make i386 user run on
>> x86_64.  What would you folks like to see in a first pass?
>>
>> sean
>>
>> ref: https://github.com/seanbruno/qemu-bsd-user/tree/bsd-user
>>
> 
> Primitive example of what I think I should base my patchset on.  Its
> invasive and large.
> 
> https://github.com/seanbruno/qemu-bsd-user/tree/merge1
> 
> That branch, is all the bsd-user changes that are pending in one large
> "splat".  It excludes the new architectures (arm, aarch64, mips, mips64)
> that we are actively using.  i386-bsd-user when compiled statically on
> x86_64 will run a static (rescue) sh ... so, I think that's good.
> x86_64 running on x86_64 just blows up.
> 
> As for sparc/sparc64 ... I'm tempted to delete them as nobody in freebsd
> is actively maintaining them nor do we have any expectation that they
> will work someday.

It's broken ... nobody maintains it ... and we've got too many
unmaintained bit-rotten files in the QEMU tree, so IMHO just go ahead
and send a patch to remove the bsud-user sparc support. If anybody ever
needs it again, they can revert the commit or simply submit a patch with
the fixed code.

 Thomas

Re: [Qemu-devel] New Year's starting over ... bsd-user

[Sean Bruno]

[-- Attachment #1: Type: text/plain, Size: 2113 bytes --]



On 01/03/17 23:53, Thomas Huth wrote:
> On 03.01.2017 18:11, Sean Bruno wrote:
>>
>>
>> On 01/03/17 09:18, Sean Bruno wrote:
>>>
>>> I'm pondering where to start with getting FreeBSD's bsd-user code into
>>> shape so it could actually be reviewed and accepted now that its sort of
>>> working again (signal handling fixed finally).
>>>
>>> I almost feel like the existing code should be purged, except that it
>>> gives a good history (and this seems lazy to me).
>>>
>>> As a first pass, I guess, I'd like to at least make i386 user run on
>>> x86_64.  What would you folks like to see in a first pass?
>>>
>>> sean
>>>
>>> ref: https://github.com/seanbruno/qemu-bsd-user/tree/bsd-user
>>>
>>
>> Primitive example of what I think I should base my patchset on.  Its
>> invasive and large.
>>
>> https://github.com/seanbruno/qemu-bsd-user/tree/merge1
>>
>> That branch, is all the bsd-user changes that are pending in one large
>> "splat".  It excludes the new architectures (arm, aarch64, mips, mips64)
>> that we are actively using.  i386-bsd-user when compiled statically on
>> x86_64 will run a static (rescue) sh ... so, I think that's good.
>> x86_64 running on x86_64 just blows up.
>>
>> As for sparc/sparc64 ... I'm tempted to delete them as nobody in freebsd
>> is actively maintaining them nor do we have any expectation that they
>> will work someday.
> 
> It's broken ... nobody maintains it ... and we've got too many
> unmaintained bit-rotten files in the QEMU tree, so IMHO just go ahead
> and send a patch to remove the bsud-user sparc support. If anybody ever
> needs it again, they can revert the commit or simply submit a patch with
> the fixed code.
> 
>  Thomas
> 
> 
> 

I agree with the exception that its way easier to nuke the sparc/64 code
after I update bsd-user.  Right now, its a tangle of #ifdef in a couple
of files that I'd like to un-tangle first.

Regardless, I can maintain the sparc/64 bsd-user target outside of qemu
until such time as someone wants to make it work or the heat death of
the universe occurs.

sean


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [Qemu-devel] New Year's starting over ... bsd-user

[Alex Bennée]

Sean Bruno <sbruno@freebsd.org> writes:

> I'm pondering where to start with getting FreeBSD's bsd-user code into
> shape so it could actually be reviewed and accepted now that its sort of
> working again (signal handling fixed finally).

Also don't forget the parallel_cpus changes which were made for enhanced
atomic support. There was also work in fixing up exclusive_start/end
which is used for safe work like tb_flush.

> I almost feel like the existing code should be purged, except that it
> gives a good history (and this seems lazy to me).
>
> As a first pass, I guess, I'd like to at least make i386 user run on
> x86_64.  What would you folks like to see in a first pass?

One thing that bugs me about linux-user is the amount of copy&paste
repetition that goes on for the main run loop. Perhaps with a clean-up
of the unused BSD architectures we could explore how a re-factored
run loop could look with a view to moving to common run-loop code across
both?

Apart from syscall mapping and backend calls to the BSD ABI what
differences are there between the two user-mode implementations?

>
> sean
>
> ref: https://github.com/seanbruno/qemu-bsd-user/tree/bsd-user


--
Alex Bennée

Re: [Qemu-devel] New Year's starting over ... bsd-user

[Sean Bruno]

[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]



On 01/04/17 11:32, Alex Bennée wrote:
> 
> Sean Bruno <sbruno@freebsd.org> writes:
> 
>> I'm pondering where to start with getting FreeBSD's bsd-user code into
>> shape so it could actually be reviewed and accepted now that its sort of
>> working again (signal handling fixed finally).
> 
> Also don't forget the parallel_cpus changes which were made for enhanced
> atomic support. There was also work in fixing up exclusive_start/end
> which is used for safe work like tb_flush.

Yeah, I ran head first into that wall last month.  :-)

We should be ok at this point as I've merged to master and am keeping up
now.

> 
>> I almost feel like the existing code should be purged, except that it
>> gives a good history (and this seems lazy to me).
>>
>> As a first pass, I guess, I'd like to at least make i386 user run on
>> x86_64.  What would you folks like to see in a first pass?
> 
> One thing that bugs me about linux-user is the amount of copy&paste
> repetition that goes on for the main run loop. Perhaps with a clean-up
> of the unused BSD architectures we could explore how a re-factored
> run loop could look with a view to moving to common run-loop code across
> both?

The bsd-user code does not have that nearly as much.  Hardware
architectures have been moved to seperate dirs and o/s support has been
broken up into seperate dirs.  This has made maintenance and testing
much easier, but not easy enough to get the code into your folk's tree.  :-)

> 
> Apart from syscall mapping and backend calls to the BSD ABI what
> differences are there between the two user-mode implementations?
> 

Not a substantial amount, IMO.  The setup and tear down are a bit
different, signal handling is a bit different, and as you mention
syscall mapping/backend calls are different.

>>
>> sean
>>
>> ref: https://github.com/seanbruno/qemu-bsd-user/tree/bsd-user
> 
> 
> --
> Alex Bennée
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [Qemu-devel] New Year's starting over ... bsd-user

[Peter Maydell]

On 4 January 2017 at 18:32, Alex Bennée <alex.bennee@linaro.org> wrote:
> Apart from syscall mapping and backend calls to the BSD ABI what
> differences are there between the two user-mode implementations?

I'm a bit wary of sharing code between the two just because
I think we'd end up breaking bsd-user all the time because
nobody who works on linux-user is in a position to test it
at all.

thanks
-- PMM

Re: [Qemu-devel] New Year's starting over ... bsd-user

[Peter Maydell]

On 3 January 2017 at 16:18, Sean Bruno <sbruno@freebsd.org> wrote:
> I'm pondering where to start with getting FreeBSD's bsd-user code into
> shape so it could actually be reviewed and accepted now that its sort of
> working again (signal handling fixed finally).
>
> I almost feel like the existing code should be purged, except that it
> gives a good history (and this seems lazy to me).
>
> As a first pass, I guess, I'd like to at least make i386 user run on
> x86_64.  What would you folks like to see in a first pass?

So, here's my thoughts on this. I think our goals here are
 * get the out-of-tree code into the tree, over time
 * help you get to a point where you're maintaining and fixing
   the FreeBSD code with us upstream, rather than deploying
   downstream patches

and the primary obstacle is this big pile of non-upstreamed
code. From my end I don't think it really matters too much
what order we try to tackle things in, as long as the chunks
that arrive for upstream review are not too large and seem at
least vaguely coherent. If i386-on-x86_64 seems like you can
extract it sensibly then I think it's as good a place to start
as anything else (though of course it's of pretty much zero
practical utility :-)).

Whether you want to keep the sparc support or delete it is
I think up to you as the maintainer -- if it's broken and
nobody cares about it I think we can happily delete it.
On the other hand if you want to fix it up and keep it around
then that's fine too.

At some point it would be good to get the BSDs into the set of
things we test when merging code, so we don't regress them.
That would ideally require hardware we can access though (the only
real-hw setup in the gcc compile farm is an ancient NetBSD
5.1 install). I guess instructions-for-BSD-novices on how to
setup a VM on a Linux box would do in a pinch.

(We should also try to avoid breaking bsd-user on the other
BSDs in the course of fixing up FreeBSD -- do you know how
many of the other BSD hosts work right now?)

thanks
-- PMM

Re: [Qemu-devel] New Year's starting over ... bsd-user

[Sean Bruno]

[-- Attachment #1: Type: text/plain, Size: 2639 bytes --]



On 01/05/17 04:33, Peter Maydell wrote:
> On 3 January 2017 at 16:18, Sean Bruno <sbruno@freebsd.org> wrote:
>> I'm pondering where to start with getting FreeBSD's bsd-user code into
>> shape so it could actually be reviewed and accepted now that its sort of
>> working again (signal handling fixed finally).
>>
>> I almost feel like the existing code should be purged, except that it
>> gives a good history (and this seems lazy to me).
>>
>> As a first pass, I guess, I'd like to at least make i386 user run on
>> x86_64.  What would you folks like to see in a first pass?
> 
> So, here's my thoughts on this. I think our goals here are
>  * get the out-of-tree code into the tree, over time
>  * help you get to a point where you're maintaining and fixing
>    the FreeBSD code with us upstream, rather than deploying
>    downstream patches
> 
> and the primary obstacle is this big pile of non-upstreamed
> code. From my end I don't think it really matters too much
> what order we try to tackle things in, as long as the chunks
> that arrive for upstream review are not too large and seem at
> least vaguely coherent. If i386-on-x86_64 seems like you can
> extract it sensibly then I think it's as good a place to start
> as anything else (though of course it's of pretty much zero
> practical utility :-)).
> 
Its a good-enough place to draw a line.  Its just an arbitrary point
that I chose.

Let me see how gruesome the patchset would be from the branch that I
created the other day.


> Whether you want to keep the sparc support or delete it is
> I think up to you as the maintainer -- if it's broken and
> nobody cares about it I think we can happily delete it.
> On the other hand if you want to fix it up and keep it around
> then that's fine too.
> 
I'll table this point for after we are merged up.

> At some point it would be good to get the BSDs into the set of
> things we test when merging code, so we don't regress them.
> That would ideally require hardware we can access though (the only
> real-hw setup in the gcc compile farm is an ancient NetBSD
> 5.1 install). I guess instructions-for-BSD-novices on how to
> setup a VM on a Linux box would do in a pinch.
> 
> (We should also try to avoid breaking bsd-user on the other
> BSDs in the course of fixing up FreeBSD -- do you know how
> many of the other BSD hosts work right now?)
> 

AFAIK, its only FreeBSD that has interest in keeping bsd-user
maintained.  OpenBSD isn't super interested in this application and
NetBSD has their own way (pkgsrc) to cross compile for other architectures.

sean


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [Qemu-devel] New Year's starting over ... bsd-user

[Sean Bruno]

[-- Attachment #1: Type: text/plain, Size: 9658 bytes --]



On 01/03/17 09:18, Sean Bruno wrote:
> 
> I'm pondering where to start with getting FreeBSD's bsd-user code into
> shape so it could actually be reviewed and accepted now that its sort of
> working again (signal handling fixed finally).
> 
> I almost feel like the existing code should be purged, except that it
> gives a good history (and this seems lazy to me).
> 
> As a first pass, I guess, I'd like to at least make i386 user run on
> x86_64.  What would you folks like to see in a first pass?
> 
> sean
> 
> ref: https://github.com/seanbruno/qemu-bsd-user/tree/bsd-user
> 


Ok, this is probably too big for a single patch.  I'll see if its
reasonable to break this up across *some* kind of logic boundary.

From 831cae735ea8f562109960401fb92fe861586dc8 Mon Sep 17 00:00:00 2001
From: Sean Bruno <sbruno@freebsd.org>
Date: Tue, 3 Jan 2017 09:57:51 -0700
Subject: [PATCH] Test branch that updates existing bsd-user code and
existing
 bsd-user targets only.

---
 Makefile.target                         |    2 +-
 bsd-user/Makefile.objs                  |    6 +-
 bsd-user/bsd-file.h                     | 1137 ++++++++++++++
 bsd-user/bsd-ioctl.c                    |  569 +++++++
 bsd-user/bsd-ioctl.h                    |   27 +
 bsd-user/bsd-mem.c                      |  124 ++
 bsd-user/bsd-mem.h                      |  438 ++++++
 bsd-user/bsd-misc.c                     |  209 +++
 bsd-user/bsd-misc.h                     |  341 +++++
 bsd-user/bsd-proc.c                     |  184 +++
 bsd-user/bsd-proc.h                     |  473 ++++++
 bsd-user/bsd-signal.h                   |  244 +++
 bsd-user/bsd-socket.c                   |  108 ++
 bsd-user/bsd-socket.h                   |  266 ++++
 bsd-user/bsdload.c                      |  171 ++-
 bsd-user/elfload.c                      | 2451
++++++++++++++++++++-----------
 bsd-user/errno_defs.h                   |   13 +-
 bsd-user/freebsd/host_os.h              |   46 +
 bsd-user/freebsd/make_syscall_nr_h.sh   |   45 +
 bsd-user/freebsd/os-extattr.c           |  118 ++
 bsd-user/freebsd/os-extattr.h           |  654 +++++++++
 bsd-user/freebsd/os-file.h              |  165 +++
 bsd-user/freebsd/os-ioctl-cmds.h        |  137 ++
 bsd-user/freebsd/os-ioctl-cryptodev.h   |   85 ++
 bsd-user/freebsd/os-ioctl-disk.h        |   53 +
 bsd-user/freebsd/os-ioctl-filio.h       |   45 +
 bsd-user/freebsd/os-ioctl-in6_var.h     |  229 +++
 bsd-user/freebsd/os-ioctl-ioccom.h      |   54 +
 bsd-user/freebsd/os-ioctl-sockio.h      |  252 ++++
 bsd-user/freebsd/os-ioctl-ttycom.h      |  257 ++++
 bsd-user/freebsd/os-ioctl-types.h       |   97 ++
 bsd-user/freebsd/os-misc.h              |  532 +++++++
 bsd-user/freebsd/os-proc.c              |  602 ++++++++
 bsd-user/freebsd/os-proc.h              |  531 +++++++
 bsd-user/freebsd/os-signal.h            |   43 +
 bsd-user/freebsd/os-socket.c            |  149 ++
 bsd-user/freebsd/os-socket.h            |  853 +++++++++++
 bsd-user/freebsd/os-stat.c              |  234 +++
 bsd-user/freebsd/os-stat.h              |  437 ++++++
 bsd-user/freebsd/os-strace.h            |   29 +
 bsd-user/freebsd/os-sys.c               | 1070 ++++++++++++++
 bsd-user/freebsd/os-thread.c            | 1419 ++++++++++++++++++
 bsd-user/freebsd/os-thread.h            |  533 +++++++
 bsd-user/freebsd/os-time.c              |  243 +++
 bsd-user/freebsd/os-time.h              |  832 +++++++++++
 bsd-user/freebsd/qemu-os.h              |   82 ++
 bsd-user/freebsd/strace.list            |   34 +-
 bsd-user/freebsd/syscall_nr.h           |  929 ++++++------
 bsd-user/freebsd/target_os_elf.h        |  151 ++
 bsd-user/freebsd/target_os_siginfo.h    |  125 ++
 bsd-user/freebsd/target_os_signal.h     |   79 +
 bsd-user/freebsd/target_os_stack.h      |  181 +++
 bsd-user/freebsd/target_os_thread.h     |    6 +
 bsd-user/freebsd/target_os_user.h       |  325 ++++
 bsd-user/freebsd/target_os_vmparam.h    |   22 +
 bsd-user/i386/target_arch.h             |   13 +
 bsd-user/i386/target_arch_cpu.c         |   80 +
 bsd-user/i386/target_arch_cpu.h         |  306 ++++
 bsd-user/i386/target_arch_elf.h         |   62 +
 bsd-user/i386/target_arch_reg.h         |   82 ++
 bsd-user/i386/target_arch_signal.h      |   94 ++
 bsd-user/i386/target_arch_sigtramp.h    |   11 +
 bsd-user/i386/target_arch_sysarch.h     |   78 +
 bsd-user/i386/target_arch_thread.h      |   45 +
 bsd-user/i386/target_arch_vmparam.h     |   28 +
 bsd-user/i386/target_signal.h           |    6 -
 bsd-user/i386/target_syscall.h          |   19 +
 bsd-user/main.c                         |  877 ++---------
 bsd-user/mmap.c                         |  416 ++++--
 bsd-user/netbsd/host_os.h               |   31 +
 bsd-user/netbsd/os-extattr.h            |  247 ++++
 bsd-user/netbsd/os-ioctl-cmds.h         |   48 +
 bsd-user/netbsd/os-ioctl-filio.h        |   29 +
 bsd-user/netbsd/os-ioctl-ioccom.h       |   38 +
 bsd-user/netbsd/os-ioctl-ttycom.h       |  240 +++
 bsd-user/netbsd/os-ioctl-types.h        |    7 +
 bsd-user/netbsd/os-misc.h               |  375 +++++
 bsd-user/netbsd/os-proc.c               |   11 +
 bsd-user/netbsd/os-proc.h               |  243 +++
 bsd-user/netbsd/os-socket.c             |    1 +
 bsd-user/netbsd/os-socket.h             |   98 ++
 bsd-user/netbsd/os-stat.c               |    1 +
 bsd-user/netbsd/os-stat.h               |    1 +
 bsd-user/netbsd/os-strace.h             |    1 +
 bsd-user/netbsd/os-sys.c                |   46 +
 bsd-user/netbsd/os-thread.c             |    1 +
 bsd-user/netbsd/os-thread.h             |  133 ++
 bsd-user/netbsd/os-time.c               |    1 +
 bsd-user/netbsd/os-time.h               |  179 +++
 bsd-user/netbsd/qemu-os.h               |    1 +
 bsd-user/netbsd/target_os_elf.h         |  227 +++
 bsd-user/netbsd/target_os_siginfo.h     |   82 ++
 bsd-user/netbsd/target_os_signal.h      |   70 +
 bsd-user/netbsd/target_os_stack.h       |   37 +
 bsd-user/netbsd/target_os_thread.h      |    6 +
 bsd-user/openbsd/host_os.h              |   31 +
 bsd-user/openbsd/os-extattr.h           |  247 ++++
 bsd-user/openbsd/os-ioctl-cmds.h        |   48 +
 bsd-user/openbsd/os-ioctl-filio.h       |   29 +
 bsd-user/openbsd/os-ioctl-ioccom.h      |   38 +
 bsd-user/openbsd/os-ioctl-ttycom.h      |  240 +++
 bsd-user/openbsd/os-ioctl-types.h       |    7 +
 bsd-user/openbsd/os-misc.h              |  375 +++++
 bsd-user/openbsd/os-proc.c              |   11 +
 bsd-user/openbsd/os-proc.h              |  243 +++
 bsd-user/openbsd/os-socket.c            |    1 +
 bsd-user/openbsd/os-socket.h            |   98 ++
 bsd-user/openbsd/os-stat.c              |    1 +
 bsd-user/openbsd/os-stat.h              |  176 +++
 bsd-user/openbsd/os-strace.h            |    1 +
 bsd-user/openbsd/os-sys.c               |   46 +
 bsd-user/openbsd/os-thread.c            |    1 +
 bsd-user/openbsd/os-thread.h            |  133 ++
 bsd-user/openbsd/os-time.c              |    1 +
 bsd-user/openbsd/os-time.h              |  179 +++
 bsd-user/openbsd/qemu-os.h              |    1 +
 bsd-user/openbsd/target_os_elf.h        |  227 +++
 bsd-user/openbsd/target_os_siginfo.h    |   82 ++
 bsd-user/openbsd/target_os_signal.h     |   70 +
 bsd-user/openbsd/target_os_stack.h      |   37 +
 bsd-user/openbsd/target_os_thread.h     |    6 +
 bsd-user/qemu-bsd.h                     |   85 ++
 bsd-user/qemu.h                         |  218 ++-
 bsd-user/signal.c                       |  896 ++++++++++-
 bsd-user/sparc/target_arch.h            |   11 +
 bsd-user/sparc/target_arch_cpu.c        |  114 ++
 bsd-user/sparc/target_arch_cpu.h        |  161 ++
 bsd-user/sparc/target_arch_elf.h        |   34 +
 bsd-user/sparc/target_arch_reg.h        |   56 +
 bsd-user/sparc/target_arch_signal.h     |   77 +
 bsd-user/sparc/target_arch_sigtramp.h   |   11 +
 bsd-user/sparc/target_arch_sysarch.h    |   52 +
 bsd-user/sparc/target_arch_thread.h     |   39 +
 bsd-user/sparc/target_arch_vmparam.h    |   37 +
 bsd-user/sparc/target_signal.h          |    5 -
 bsd-user/sparc/target_syscall.h         |   24 +-
 bsd-user/sparc64/target_arch.h          |   17 +
 bsd-user/sparc64/target_arch_cpu.c      |  122 ++
 bsd-user/sparc64/target_arch_cpu.h      |  284 ++++
 bsd-user/sparc64/target_arch_elf.h      |   38 +
 bsd-user/sparc64/target_arch_reg.h      |   56 +
 bsd-user/sparc64/target_arch_signal.h   |  188 +++
 bsd-user/sparc64/target_arch_sigtramp.h |   12 +
 bsd-user/sparc64/target_arch_sysarch.h  |  158 ++
 bsd-user/sparc64/target_arch_thread.h   |   57 +
 bsd-user/sparc64/target_arch_vmparam.h  |   37 +
 bsd-user/sparc64/target_signal.h        |    5 -
 bsd-user/sparc64/target_syscall.h       |   24 +-
 bsd-user/strace.c                       |   10 +
 bsd-user/syscall.c                      | 2086 +++++++++++++++++++++-----
 bsd-user/syscall_defs.h                 |  929 ++++++++++--
 bsd-user/x86_64/target_arch.h           |   13 +
 bsd-user/x86_64/target_arch_cpu.c       |   80 +
 bsd-user/x86_64/target_arch_cpu.h       |  321 ++++
 bsd-user/x86_64/target_arch_elf.h       |   55 +
 bsd-user/x86_64/target_arch_reg.h       |   92 ++
 bsd-user/x86_64/target_arch_signal.h    |   94 ++
 bsd-user/x86_64/target_arch_sigtramp.h  |   11 +
 bsd-user/x86_64/target_arch_sysarch.h   |   76 +
 bsd-user/x86_64/target_arch_thread.h    |   40 +
 bsd-user/x86_64/target_arch_vmparam.h   |   28 +
 bsd-user/x86_64/target_signal.h         |    5 -
 bsd-user/x86_64/target_syscall.h        |   21 +-
 configure


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [Qemu-devel] New Year's starting over ... bsd-user

[Peter Maydell]

On 5 January 2017 at 16:03, Sean Bruno <sbruno@freebsd.org> wrote:
> Ok, this is probably too big for a single patch.  I'll see if its
> reasonable to break this up across *some* kind of logic boundary.

Yeah, that's pretty huge. My rough rule of thumb: prefer
each patch to be <500 lines, prefer <20 patches in a patchset.

thanks
-- PMM

Re: [Qemu-devel] New Year's starting over ... bsd-user

[Sean Bruno]

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]



On 01/05/17 09:11, Peter Maydell wrote:
> On 5 January 2017 at 16:03, Sean Bruno <sbruno@freebsd.org> wrote:
>> Ok, this is probably too big for a single patch.  I'll see if its
>> reasonable to break this up across *some* kind of logic boundary.
> 
> Yeah, that's pretty huge. My rough rule of thumb: prefer
> each patch to be <500 lines, prefer <20 patches in a patchset.
> 
> thanks
> -- PMM
> 

Ok, let's try a small one patch change for the first pass while I work
on a larger patch series.

sean


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [Qemu-devel] New Year's starting over ... bsd-user

[Philippe Mathieu-Daudé]

[Reviving an old thread]

Hi Sean,

On 1/3/17 5:18 PM, Sean Bruno wrote:
> I'm pondering where to start with getting FreeBSD's bsd-user code into
> shape so it could actually be reviewed and accepted now that its sort of
> working again (signal handling fixed finally).
> 
> I almost feel like the existing code should be purged, except that it
> gives a good history (and this seems lazy to me).
> 
> As a first pass, I guess, I'd like to at least make i386 user run on
> x86_64.  What would you folks like to see in a first pass?
> 
> sean
> 
> ref: https://github.com/seanbruno/qemu-bsd-user/tree/bsd-user

Looking at your repository I see you are still active and merging
patches from other users.

Could you summarize how your tree differs from the upstream one?
I guess your work could benefit other users, stucked at the current
broken state of bsd-user.

Some users who reported they switched to the Unicorn Engine [*], I
haven't looked at it yet, since I found this thread first, while reading
on deprecating unsupported code (another old thread):
https://lists.gnu.org/archive/html/qemu-devel/2017-03/msg03519.html

Thanks,

Phil.

[*] https://www.unicorn-engine.org/