qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [RFC] linux-user (mostly syscall.c)


From: Thayne Harbaugh
Subject: [Qemu-devel] [RFC] linux-user (mostly syscall.c)
Date: Fri, 02 Nov 2007 18:05:43 -0600

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.

Thank you.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]