All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thiemo Seufer <ths@networkno.de>
To: Thayne Harbaugh <thayne@c2.net>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [RFC] linux-user (mostly syscall.c)
Date: Sat, 3 Nov 2007 01:21:23 +0000	[thread overview]
Message-ID: <20071103012123.GB10975@networkno.de> (raw)
In-Reply-To: <1194048343.2168.48.camel@phantasm.home.enterpriseandprosperity.com>

Thayne Harbaugh wrote:
> There are several things that I'd like to see addressed in linux-user.
> Some of these are to fix bugs, some are to make qemu linux-user more
> like the Linux kernel, some are to make the internal qemu interfaces
> more consistent.
> 
> An internal coding practice that is being addressed bit-by-bit is that
> of managing the interface between the host and the target.  Currently
> this is a bit sloppy and inconsistent (some of which I've contributed
> to).  There are examples of using target addresses for host pointers and
> host errnos for target errnos, using different types between target and
> host that don't sign-extend properly, as well as other things.  This
> causes compiler warnings to actual run-time bugs.  Currently I'm
> reviewing all of the linux-user code (mostly syscall.c) to fix these
> inconsistencies.  I will be writing developer documentation describing
> the coding practices that should govern the target/host interface and
> submitting patches for the fixes.
> 
> As obvious as it may seem I'll re-state that the linux-user emulation is
> emulating the Linux kernel (duh!).  There are portions of qemu
> linux-user that are even excerpted directly from the Linux kernel.
> Consequently it is useful for internal qemu data and functions to
> closely mimic the kernel for best code sharing.  There are also
> advantages to even structuring qemu directly and file organization in
> similar divisions, groupings and locations.  Some of this organization
> might lead to good division so that other user/kernel divisions are
> cleaner (different kernel versions, other OSes - darwin-user and
> others).
> 
> Internal qemu interfaces are consistent - except when they aren't.  This
> causes coding errors when passing target and host arguments or return
> codes.  I'll be documenting the coding practices as well as submitting
> patches to make these consistent.  (That sounds a bit redundant with
> other things I've mentioned).
> 
> I have about 40 patches already worked up that do this.  Some of those
> patches might be broken up smaller.  The qemu that we've been working
> with is nearly rock solid (still a few more bugs being wrung out).  It
> can nearly build an entire Debian arm distribution for an arm target
> being hosted on x86_64.  We're quite excited to get our patches upstream
> so that others can benefit and to ease our maintenance overhead.  We're
> also turning our focus to PPC and other archs.
> 
> Please let me know if you support the general idea of the coding changes
> above: General clean-up, consistent target/host interfaces, file
> splitting/reorganizing, etc..  In the meantime I'll be putting together
> the developer documentation/coding guidelines for review.

FWIW, I agree with everything you said above.


Thiemo

  reply	other threads:[~2007-11-03  1:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-03  0:05 [Qemu-devel] [RFC] linux-user (mostly syscall.c) Thayne Harbaugh
2007-11-03  1:21 ` Thiemo Seufer [this message]
2007-11-03 12:52   ` J. Mayer
2007-11-03 14:15     ` Thayne Harbaugh
2007-11-03 19:13       ` Fabrice Bellard
2007-11-04  1:16         ` Thayne Harbaugh
2007-11-04  1:35           ` J. Mayer
2007-11-04  1:51             ` Paul Brook
2007-11-04  7:49               ` J. Mayer
2007-11-03 17:24 ` TJ

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071103012123.GB10975@networkno.de \
    --to=ths@networkno.de \
    --cc=qemu-devel@nongnu.org \
    --cc=thayne@c2.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.