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-)
