From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Io7hc-0004dp-Go for qemu-devel@nongnu.org; Fri, 02 Nov 2007 21:21:32 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Io7hb-0004d5-G5 for qemu-devel@nongnu.org; Fri, 02 Nov 2007 21:21:32 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Io7hb-0004cm-A3 for qemu-devel@nongnu.org; Fri, 02 Nov 2007 21:21:31 -0400 Received: from relay01.mx.bawue.net ([193.7.176.67]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Io7ha-0002La-W6 for qemu-devel@nongnu.org; Fri, 02 Nov 2007 21:21:31 -0400 Date: Sat, 3 Nov 2007 01:21:23 +0000 From: Thiemo Seufer Subject: Re: [Qemu-devel] [RFC] linux-user (mostly syscall.c) Message-ID: <20071103012123.GB10975@networkno.de> References: <1194048343.2168.48.camel@phantasm.home.enterpriseandprosperity.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1194048343.2168.48.camel@phantasm.home.enterpriseandprosperity.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thayne Harbaugh Cc: qemu-devel 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