On Wed, Dec 21, 2016 at 12:21:44PM +0100, Paolo Bonzini wrote: > > > On 20/12/2016 18:43, Eduardo Habkost wrote: > > This moves the KVM and Xen files to the an accel/ subdir. > > > > Instead of moving the *-stubs.c file to accel/ as-is, I tried to > > move most of the stub code to libqemustub.a. This way the obj-y > > logic for accel/ is simpler: obj-y includes accel/ only if > > CONFIG_SOFTMMU is set. > > > > The Xen stubs could be moved completely to stubs/, but some of > > the KVM stubs depend on cpu.h. So most of the kvm-stub.c code was > > moved to stubs/kvm.c, but some of that code was kept in > > accel/kvm-stub.c. > > I think we need to decide what libqemustub is for. > > The original purpose was to provide different implementations of some > functions for tools vs. emulators or (more rarely) for user-mode vs. > system emulation. > So, is sysemu vs user-mode a valid reason for using libqemustub? The main reason I have moved some code to sbus/kvm.c is to avoid having to include accel/kvm-stub.c in *-user. Moving xen-stub.c to libqemustub, on the other hand, is really unnecessary. > There are also some cases where we use it for functions that are only > implemented by some targets. > > In general, I think libqemustub should be the last resort. If possible, > inlines in headers should be the first choice, and stubs in objs-y or > common-objs-y (using $(call lnot) in the Makefile) should be the second. I understand the reasoning, but I fail to see cases when libqemustub would be considered appropriate. Using stubs in obj-y/common-obj-y using $(call lnot) is always possible, isn't it? Hmm, maybe on cases where the decision to use the stub doesn't depend on a single build variable (e.g. a function implemented by a handful of targets, but not all of them). Are there other examples? > > The reason is that stubs/ hides files from the corresponding maintainer; > for example, commit 07a32d6b's addition of stubs/get-next-serial.c was > in all likelihood unnecessary, but the new file went in without an ack > for a character device maintainer. Tracking stubs in the MAINTAINERS > file is unwieldy and, from this point of view, I find > > F: accel/kvm* > > to be preferrable to > > F: accel/kvm* > F: stubs/kvm.c > > Thanks, > > Paolo > > > About TCG: > > ---------- > > > > It is not obvious to me which TCG-related files could be moved to > > accel/, so this series don't move any of them yet. > > > > About other CONFIG_SOFTMMU top-level files: > > ------------------------------------------- > > > > I would like to know what we should do with the top-level > > CONFIG_SOFTMMU-only files that don't belong to hw/. Some > > candidates: arch_init.c cpus.c monitor.c gdbstub.c balloon.c > > ioport.c bootdevice.c memory.c cputlb.c memory_mapping.c dump.c. > > > > Maybe a sysemu/ subdir? In that case, should we still create an > > accel/ subdir, or move xen-*, kvm-* and friends to sysemu/ too? > > > > Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx> > > Cc: kvm@xxxxxxxxxxxxxxx > > Cc: Christoffer Dall <christoffer.dall@xxxxxxxxxx> > > Cc: Anthony Perard <anthony.perard@xxxxxxxxxx> > > Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx> > > Cc: xen-devel@xxxxxxxxxxxxxxxxxxx > > > > Eduardo Habkost (7): > > xen: Move xen-*-stub.c to stubs/ > > xen: Move xen files to accel/ > > kvm: Move some kvm-stub.c code to stubs/kvm.c > > kvm: Include kvm-stub.o only on CONFIG_SOFTMMU > > kvm: Move kvm*.c files to accel/ > > accel: Move accel.c to accel/ > > accel: Move qtest.c to accel/ -- Eduardo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
