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

[Thayne Harbaugh]

On Sat, 2007-11-03 at 13:52 +0100, J. Mayer wrote:
> On Sat, 2007-11-03 at 01:21 +0000, Thiemo Seufer wrote:
> > 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.
> 
> I agree too.
> Code cleanup and sanitization is needed there.
> I'm just reserved about the code splitting point: as for the vl.h
> splitting, it should not lead to get files with only a single or two
> small function inside.

Right now I have it split similar to the Linux kernel.  It has
reasonable code grouping and makes it easy to compare code with the
kernel.

>  But it could be great to group the syscalls by
> categories, or so. For example, putting all POSIX compliant syscalls in
> a single file and using a syscall table could make quite easy to develop
> a BSD-user target (I did this in the past, not in Qemu though...). POSIX
> compliant interfaces can mostly be shared with Linux ones and a lot of
> other syscalls are common to the 3 BSD flavors (Net, Open and Free..).
> Being able to add a BSD target sharing the same code would be a proof
> the code is flexible and well organized; I guess large parts of the
> Darwin user target could also be merged with a FreeBSD user target...

That's a reasonable strategy as well.  I've looked through some of the
darwin code and have considered how common code could be merged.

> Just my few cents ideas, don't say it has to be implemented soon, just
> think keeping those long-term goals in mind may help having a flexible
> and clean implementation...

It's likely closer than you realize. 8-)