Re: [Qemu-devel] directory hierarchy
On 09/23/2012 06:07 PM, Blue Swirl wrote: On Sun, Sep 23, 2012 at 8:25 AM, Avi Kivity a...@redhat.com wrote: On 09/22/2012 04:15 PM, Blue Swirl wrote: This could have nice cleanup effects though and for example enable generic 'info vmtree' to discover VA-PA mappings for any target instead of current MMU table walkers. How? That's in a hardware defined format that's completely invisible to the memory API. It's invisible now, but target-specific code could grab the mappings and feed them to memory API. Memory API would just see the per-CPU virtual memory as address spaces that map to physical memory address space. For RAM backed MMU tables like x86 and Sparc32, writes to page table memory areas would need to be tracked like SMC. For in-MMU TLBs, this would not be needed. Again, if performance would degrade, this would not be worthwhile. I'd expect VA-PA mappings to change at least at context switch rate + page fault rate + mmap/exec activity so this could amount to thousands of changes per second per CPU. In theory KVM could use memory API as CPU type agnostic way to exchange this information, I'd expect that KVM exit rate is not nearly as big and in many cases exchange of mapping information would not be needed. It would not improve performance there either. Perhaps I was not very clear, but this was just theoretical. First, the memory API does not operate at that level. It handles (guest physical) - (host virtual | io callback) translations. These are (guest virtual) - (guest physical translations). I don't see why memory API could not be used also for GVA-GPA translation if we ignore performance for the sake of discussion. For the reasons I mentioned. The guest doesn't issue calls into the memory API. The granularity is wrong. It is a system-wide API. The latter two issues have to change to support IOMMUs, and then indeed the memory API will be much closer to a CPU MMU (on x86 they can even share page tables in some circumstances). It will still be the wrong API IMO. Second, the memory API is machine-wide and designed for coarse maps. Processor memory maps are per-cpu and page-grained. (the memory API actually needs to efficiently support page-grained maps (for iommus) and per-cpu maps (smm), but that's another story). Third, we know from the pre-npt/ept days that tracking all mappings destroys performance. It's much better to do this on demand. Yes, performance reasons kill this idea. It would still be beautiful. Maybe I'm missing something, but I don't see this. But as you said, it's theoretical. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] directory hierarchy
On 09/22/2012 04:15 PM, Blue Swirl wrote: This could have nice cleanup effects though and for example enable generic 'info vmtree' to discover VA-PA mappings for any target instead of current MMU table walkers. How? That's in a hardware defined format that's completely invisible to the memory API. It's invisible now, but target-specific code could grab the mappings and feed them to memory API. Memory API would just see the per-CPU virtual memory as address spaces that map to physical memory address space. For RAM backed MMU tables like x86 and Sparc32, writes to page table memory areas would need to be tracked like SMC. For in-MMU TLBs, this would not be needed. Again, if performance would degrade, this would not be worthwhile. I'd expect VA-PA mappings to change at least at context switch rate + page fault rate + mmap/exec activity so this could amount to thousands of changes per second per CPU. In theory KVM could use memory API as CPU type agnostic way to exchange this information, I'd expect that KVM exit rate is not nearly as big and in many cases exchange of mapping information would not be needed. It would not improve performance there either. First, the memory API does not operate at that level. It handles (guest physical) - (host virtual | io callback) translations. These are (guest virtual) - (guest physical translations). Second, the memory API is machine-wide and designed for coarse maps. Processor memory maps are per-cpu and page-grained. (the memory API actually needs to efficiently support page-grained maps (for iommus) and per-cpu maps (smm), but that's another story). Third, we know from the pre-npt/ept days that tracking all mappings destroys performance. It's much better to do this on demand. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
Re: [Qemu-devel] directory hierarchy
On Sun, Sep 23, 2012 at 8:25 AM, Avi Kivity a...@redhat.com wrote: On 09/22/2012 04:15 PM, Blue Swirl wrote: This could have nice cleanup effects though and for example enable generic 'info vmtree' to discover VA-PA mappings for any target instead of current MMU table walkers. How? That's in a hardware defined format that's completely invisible to the memory API. It's invisible now, but target-specific code could grab the mappings and feed them to memory API. Memory API would just see the per-CPU virtual memory as address spaces that map to physical memory address space. For RAM backed MMU tables like x86 and Sparc32, writes to page table memory areas would need to be tracked like SMC. For in-MMU TLBs, this would not be needed. Again, if performance would degrade, this would not be worthwhile. I'd expect VA-PA mappings to change at least at context switch rate + page fault rate + mmap/exec activity so this could amount to thousands of changes per second per CPU. In theory KVM could use memory API as CPU type agnostic way to exchange this information, I'd expect that KVM exit rate is not nearly as big and in many cases exchange of mapping information would not be needed. It would not improve performance there either. Perhaps I was not very clear, but this was just theoretical. First, the memory API does not operate at that level. It handles (guest physical) - (host virtual | io callback) translations. These are (guest virtual) - (guest physical translations). I don't see why memory API could not be used also for GVA-GPA translation if we ignore performance for the sake of discussion. Second, the memory API is machine-wide and designed for coarse maps. Processor memory maps are per-cpu and page-grained. (the memory API actually needs to efficiently support page-grained maps (for iommus) and per-cpu maps (smm), but that's another story). Third, we know from the pre-npt/ept days that tracking all mappings destroys performance. It's much better to do this on demand. Yes, performance reasons kill this idea. It would still be beautiful. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
Re: [Qemu-devel] directory hierarchy
On Thu, Sep 20, 2012 at 11:31 AM, Avi Kivity a...@redhat.com wrote: On 09/19/2012 10:57 PM, Blue Swirl wrote: On Wed, Sep 19, 2012 at 12:54 PM, Avi Kivity a...@redhat.com wrote: On 09/14/2012 10:51 PM, Blue Swirl wrote: exec: These files need cleanup so that TCG code gets into tcg/. Maybe also TB and CPUTLB handling. Some of that could be done by adding a separate MemoryListener for tcg. But the TBs and CPUTLB are based on virtual mappings, it would mean that MMU maps would have to be modeled using memory API. Is that fast enough? No. The memory API is designed to be fast on reads at the expense of being slow on writes, and this will get worse as rcu is added. I meant that the various calls to invalidate tcg-specific caches can use a tcg-specific MemoryListener. Maybe. This could have nice cleanup effects though and for example enable generic 'info vmtree' to discover VA-PA mappings for any target instead of current MMU table walkers. How? That's in a hardware defined format that's completely invisible to the memory API. It's invisible now, but target-specific code could grab the mappings and feed them to memory API. Memory API would just see the per-CPU virtual memory as address spaces that map to physical memory address space. For RAM backed MMU tables like x86 and Sparc32, writes to page table memory areas would need to be tracked like SMC. For in-MMU TLBs, this would not be needed. Again, if performance would degrade, this would not be worthwhile. I'd expect VA-PA mappings to change at least at context switch rate + page fault rate + mmap/exec activity so this could amount to thousands of changes per second per CPU. In theory KVM could use memory API as CPU type agnostic way to exchange this information, I'd expect that KVM exit rate is not nearly as big and in many cases exchange of mapping information would not be needed. It would not improve performance there either. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] directory hierarchy
On 09/19/2012 10:57 PM, Blue Swirl wrote: On Wed, Sep 19, 2012 at 12:54 PM, Avi Kivity a...@redhat.com wrote: On 09/14/2012 10:51 PM, Blue Swirl wrote: exec: These files need cleanup so that TCG code gets into tcg/. Maybe also TB and CPUTLB handling. Some of that could be done by adding a separate MemoryListener for tcg. But the TBs and CPUTLB are based on virtual mappings, it would mean that MMU maps would have to be modeled using memory API. Is that fast enough? No. The memory API is designed to be fast on reads at the expense of being slow on writes, and this will get worse as rcu is added. I meant that the various calls to invalidate tcg-specific caches can use a tcg-specific MemoryListener. This could have nice cleanup effects though and for example enable generic 'info vmtree' to discover VA-PA mappings for any target instead of current MMU table walkers. How? That's in a hardware defined format that's completely invisible to the memory API. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] directory hierarchy
On 09/14/2012 10:51 PM, Blue Swirl wrote: exec: These files need cleanup so that TCG code gets into tcg/. Maybe also TB and CPUTLB handling. Some of that could be done by adding a separate MemoryListener for tcg. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] directory hierarchy
On Wed, Sep 19, 2012 at 12:54 PM, Avi Kivity a...@redhat.com wrote: On 09/14/2012 10:51 PM, Blue Swirl wrote: exec: These files need cleanup so that TCG code gets into tcg/. Maybe also TB and CPUTLB handling. Some of that could be done by adding a separate MemoryListener for tcg. But the TBs and CPUTLB are based on virtual mappings, it would mean that MMU maps would have to be modeled using memory API. Is that fast enough? This could have nice cleanup effects though and for example enable generic 'info vmtree' to discover VA-PA mappings for any target instead of current MMU table walkers. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] directory hierarchy
Il 16/09/2012 16:40, Anthony Liguori ha scritto: It's good to put includes in a single direction such that you can do -Iinclude and then: #include qemu/foo.h Which is better than: #include foo.h Because the later can create confusion/conflict with system headers whereas the former is (hopefully) completely unambiguous. My plan for this is to only put directories in include/, which limits a lot the possibility of confusion, for example #include exec/cpu-all.h #include qapi/qapi-types.h etc. Unfortunately, this _does_ require touching every .c file. Moving to include/ would be to clean up the top-level directory, withour touching the source code. If something can be moved directly to one of the new source directories, that's also fine but I don't have high hopes. I actually thinking moving to -Iinclude is a Good Thing for now because it avoids touching a bunch of .c files. In the longer term, we should continue to clean up headers and move them into qemu/ though. I disagree about qemu/ vs. other directories, but yes, it is better to avoid touching .c files at the same time you're moving them. It is not completely possible, mostly because some header files in net/ combine both private content (which should move to sysemu/net/) and public content (which should move to include/net/), but that should be the exception. Paolo
Re: [Qemu-devel] directory hierarchy
Il 16/09/2012 16:44, Anthony Liguori ha scritto: Thanks for doing this! I'm of the opinion that something is better than nothing here so I'll resist the urge to argue why blue is the best color for the shed. But one concern I have: this will be a big source of rebasing. Perhaps we can schedule this? From what I've seen so far, rebase copes well with renames. But yes, I'm willing to maintain the series until the end of October. Have you done the reorg yet? I'm 90% through. I hope to post something for review, and perhaps some initial bits, in a couple of weeks or less (depending on other obviously more urgent things to do). But if it's 1 month away, I'd probably prefer to merge the include file renaming at the same time. Presumably it's just some make file changes and a bunch of renames? Mostly; net/ is the hairiest subsystem, otherwise it's pretty straightforward. Paolo
Re: [Qemu-devel] directory hierarchy
Paolo Bonzini pbonz...@redhat.com writes: Il 16/09/2012 16:44, Anthony Liguori ha scritto: Thanks for doing this! I'm of the opinion that something is better than nothing here so I'll resist the urge to argue why blue is the best color for the shed. But one concern I have: this will be a big source of rebasing. Perhaps we can schedule this? From what I've seen so far, rebase copes well with renames. It does, but git-am doesn't. I've never had much luck with --3way either. But yes, I'm willing to maintain the series until the end of October. Okay, if it gets onerous to maintain, we can try to merge it earlier, but let's shoot for the end of October for now to give people a chance to get things merged. Have you done the reorg yet? I'm 90% through. I hope to post something for review, and perhaps some initial bits, in a couple of weeks or less (depending on other obviously more urgent things to do). But if it's 1 month away, I'd probably prefer to merge the include file renaming at the same time. That's reasonable. Regards, Anthony Liguori Presumably it's just some make file changes and a bunch of renames? Mostly; net/ is the hairiest subsystem, otherwise it's pretty straightforward. Paolo
Re: [Qemu-devel] directory hierarchy
Paolo Bonzini pbonz...@redhat.com writes: Il 14/09/2012 15:36, Peter Maydell ha scritto: On 14 September 2012 14:17, Paolo Bonzini pbonz...@redhat.com wrote: here is a proposal for moving around 150 C files currently in the toplevel directory to separate, well-delimited subdirectories. No general objection (though some specific comments below). However I think it would be helpful if you could provide some descriptions of how your new subdirectories are defined. Otherwise the well-delimited bit is largely in your head and future new files aren't likely to respect it except by accident :-) Good question. I just tried to use some taste, so well-delimited is a bit of a lie. I mostly care that sysemu/, tools/, qga/ and user/ are well-delimited, i.e. executables do not have sources from other executables' directories, and similarly common/ is just for emulators. Header files would be moved for now in include/, preparing for subsequent reorganization of headers. Just in include/, or in include/qemu/ ? (IIRC Anthony was hoping to only move cleaned-up headers in there?) I dislike include/qemu, for the same reason I dislike qemu-*. :) It's good to put includes in a single direction such that you can do -Iinclude and then: #include qemu/foo.h Which is better than: #include foo.h Because the later can create confusion/conflict with system headers whereas the former is (hopefully) completely unambiguous. Moving to include/ would be to clean up the top-level directory, withour touching the source code. If something can be moved directly to one of the new source directories, that's also fine but I don't have high hopes. I actually thinking moving to -Iinclude is a Good Thing for now because it avoids touching a bunch of .c files. In the longer term, we should continue to clean up headers and move them into qemu/ though. Regards, Anthony Liguori
Re: [Qemu-devel] directory hierarchy
Paolo Bonzini pbonz...@redhat.com writes: Hi all, here is a proposal for moving around 150 C files currently in the toplevel directory to separate, well-delimited subdirectories. Header files would be moved for now in include/, preparing for subsequent reorganization of headers. Usually the files would keep their names, but I loathe names starting with qemu-* so I took the occasion to rename those. This does not touch the hw/ directory, which is its own mess and worth a separate discussion. Cleaning it up may require introducing more CONFIG_* symbols and moving stuff to libhw whenever possible (for example if we want all NICs in hw/net, all RTCs in hw/rtc, etc. perhaps with some exceptions for USB). Opinions, flames, stop this guys are welcome as usual. Thanks for doing this! I'm of the opinion that something is better than nothing here so I'll resist the urge to argue why blue is the best color for the shed. But one concern I have: this will be a big source of rebasing. Perhaps we can schedule this? Have you done the reorg yet? Presumably it's just some make file changes and a bunch of renames? Perhaps we can schedule it for November 1st to mark the start of the soft freeze. Since many of us are traveling afterwards, I expect there won't be a lot of last minute merging for this release. Regards, Anthony Liguori Paolo block: aes.c aio.c async.c block.c blockjob.c (with plans to move it in sysemu/block) nbd.c qemu-progress.c block/progress.c block/coroutine: coroutine-gthread.c block/coroutine/gthread.c coroutine-sigaltstack.c block/coroutine/sigaltstack.c coroutine-ucontext.cblock/coroutine/ucontext.c coroutine-win32.c block/coroutine/win32.c qemu-coroutine-io.c block/coroutine/io.c qemu-coroutine-lock.c block/coroutine/lock.c qemu-coroutine-sleep.c block/coroutine/sleep.c qemu-coroutine.cblock/coroutine/coroutine.c block/drivers: block/blkdebug.c block/blkverify.c block/bochs.c block/cloop.c block/cow.c block/curl.c block/dmg.c block/iscsi.c block/mirror.c block/nbd.c block/parallels.c block/qcow.c block/qcow2-cache.c block/qcow2-cluster.c block/qcow2-refcount.c block/qcow2-snapshot.c block/qcow2.c block/qed-check.c block/qed-cluster.c block/qed-gencb.c block/qed-l2-cache.c block/qed-table.c block/qed.c block/raw-posix.c block/raw-win32.c block/raw.c block/rbd.c block/sheepdog.c block/vdi.c block/vmdk.c block/vpc.c block/vvfat.c linux-aio.c posix-aio-compat.c exec: cpu-exec.c disas.c exec.c gdbstub.c tci.c (note: TCI can't go in tcg/ for licensing reasons) translate-all.c hw: hw/dma.chw/i8257.c dma-helpers.c hw/dma.c libdis: alpha-dis.c libdis/alpha.c arm-dis.c libdis/arm.c cris-dis.c libdis/cris.c hppa-dis.c libdis/hppa.c i386-dis.c libdis/i386.c ia64-dis.c libdis/ia64.c lm32-dis.c libdis/lm32.c m68k-dis.c libdis/m68k.c microblaze-dis.clibdis/microblaze.c mips-dis.c libdis/mips.c ppc-dis.c libdis/ppc.c s390-dis.c libdis/s390.c sh4-dis.c libdis/sh4.c sparc-dis.c libdis/sparc.c tci-dis.c libdis/tci.c net: net.c qapi: error.c qga: qemu-ga.c qga/main.c qobject: json-lexer.c json-parser.c json-streamer.c qbool.c qdict.c qerror.c qfloat.c qint.c qjson.c qlist.c qstring.c sysemu: arch_init.c balloon.c cpus.c cputlb.c cursor.c device_tree.c dump-stub.c dump.c ioport.c kvm-all.c kvm-stub.c memory.c memory_mapping-stub.c memory_mapping.c os-posix.c os-win32.c pflib.c qemu-error.csysemu/error.c qemu-seccomp.c sysemu/seccomp.c qtest.c vl.c xen-all.c xen-mapcache.c xen-stub.c qemu-options.hx sysemu/block: block/stream.c blockdev.c sysemu/bt: bt-host.c sysemu/bt/host.c bt-vhci.c sysemu/bt/vhci.c sysemu/char: qemu-char.c sysemu/char/chardev.c qemu-sockets.c sysemu/char/sockets.c spice-qemu-char.c sysemu/char/spice.c sysemu/migration: block-migration.c migration/block.c buffered_file.c migration-exec.c migration-fd.c migration-tcp.c migration-unix.c migration.c page_cache.c savevm.c sysemu/monitor: hmp.c monitor.c qmp.c readline.c hmp-commands.hx qmp-commands.hx tcg: tcg-runtime.c tcg/runtime.c tools: cmd.c qemu-bridge-helper.c qemu-img.c qemu-img-cmds.hx qemu-io.c qemu-nbd.c qemu-tool.c tools/stub.c ui: console.c input.c user: qemu-user.c user/stub.c thunk.c user-exec.c
[Qemu-devel] directory hierarchy
Hi all, here is a proposal for moving around 150 C files currently in the toplevel directory to separate, well-delimited subdirectories. Header files would be moved for now in include/, preparing for subsequent reorganization of headers. Usually the files would keep their names, but I loathe names starting with qemu-* so I took the occasion to rename those. This does not touch the hw/ directory, which is its own mess and worth a separate discussion. Cleaning it up may require introducing more CONFIG_* symbols and moving stuff to libhw whenever possible (for example if we want all NICs in hw/net, all RTCs in hw/rtc, etc. perhaps with some exceptions for USB). Opinions, flames, stop this guys are welcome as usual. Paolo block: aes.c aio.c async.c block.c blockjob.c (with plans to move it in sysemu/block) nbd.c qemu-progress.c block/progress.c block/coroutine: coroutine-gthread.c block/coroutine/gthread.c coroutine-sigaltstack.c block/coroutine/sigaltstack.c coroutine-ucontext.cblock/coroutine/ucontext.c coroutine-win32.c block/coroutine/win32.c qemu-coroutine-io.c block/coroutine/io.c qemu-coroutine-lock.c block/coroutine/lock.c qemu-coroutine-sleep.c block/coroutine/sleep.c qemu-coroutine.cblock/coroutine/coroutine.c block/drivers: block/blkdebug.c block/blkverify.c block/bochs.c block/cloop.c block/cow.c block/curl.c block/dmg.c block/iscsi.c block/mirror.c block/nbd.c block/parallels.c block/qcow.c block/qcow2-cache.c block/qcow2-cluster.c block/qcow2-refcount.c block/qcow2-snapshot.c block/qcow2.c block/qed-check.c block/qed-cluster.c block/qed-gencb.c block/qed-l2-cache.c block/qed-table.c block/qed.c block/raw-posix.c block/raw-win32.c block/raw.c block/rbd.c block/sheepdog.c block/vdi.c block/vmdk.c block/vpc.c block/vvfat.c linux-aio.c posix-aio-compat.c exec: cpu-exec.c disas.c exec.c gdbstub.c tci.c (note: TCI can't go in tcg/ for licensing reasons) translate-all.c hw: hw/dma.chw/i8257.c dma-helpers.c hw/dma.c libdis: alpha-dis.c libdis/alpha.c arm-dis.c libdis/arm.c cris-dis.c libdis/cris.c hppa-dis.c libdis/hppa.c i386-dis.c libdis/i386.c ia64-dis.c libdis/ia64.c lm32-dis.c libdis/lm32.c m68k-dis.c libdis/m68k.c microblaze-dis.clibdis/microblaze.c mips-dis.c libdis/mips.c ppc-dis.c libdis/ppc.c s390-dis.c libdis/s390.c sh4-dis.c libdis/sh4.c sparc-dis.c libdis/sparc.c tci-dis.c libdis/tci.c net: net.c qapi: error.c qga: qemu-ga.c qga/main.c qobject: json-lexer.c json-parser.c json-streamer.c qbool.c qdict.c qerror.c qfloat.c qint.c qjson.c qlist.c qstring.c sysemu: arch_init.c balloon.c cpus.c cputlb.c cursor.c device_tree.c dump-stub.c dump.c ioport.c kvm-all.c kvm-stub.c memory.c memory_mapping-stub.c memory_mapping.c os-posix.c os-win32.c pflib.c qemu-error.csysemu/error.c qemu-seccomp.c sysemu/seccomp.c qtest.c vl.c xen-all.c xen-mapcache.c xen-stub.c qemu-options.hx sysemu/block: block/stream.c blockdev.c sysemu/bt: bt-host.c sysemu/bt/host.c bt-vhci.c sysemu/bt/vhci.c sysemu/char: qemu-char.c sysemu/char/chardev.c qemu-sockets.c sysemu/char/sockets.c spice-qemu-char.c sysemu/char/spice.c sysemu/migration: block-migration.c migration/block.c buffered_file.c migration-exec.c migration-fd.c migration-tcp.c migration-unix.c migration.c page_cache.c savevm.c sysemu/monitor: hmp.c monitor.c qmp.c readline.c hmp-commands.hx qmp-commands.hx tcg: tcg-runtime.c tcg/runtime.c tools: cmd.c qemu-bridge-helper.c qemu-img.c qemu-img-cmds.hx qemu-io.c qemu-nbd.c qemu-tool.c tools/stub.c ui: console.c input.c user: qemu-user.c user/stub.c thunk.c user-exec.c user/cpu-exec.c util: acl.c bitmap.c bitops.c cache-utils.c compatfd.c cutils.c envlist.c event_notifier.c host-utils.c iohandler.c iov.c main-loop.c module.c notify.c osdep.c oslib-posix.c oslib-win32.c path.c qemu-config.c util/config.c qemu-log.c util/log.c qemu-option.c util/option.c qemu-thread-posix.c util/thread-posix.c qemu-thread-win32.c util/thread-win32.c qemu-timer-common.c util/clock.c qemu-timer.cutil/timer.c
Re: [Qemu-devel] directory hierarchy
On 14 September 2012 14:17, Paolo Bonzini pbonz...@redhat.com wrote: here is a proposal for moving around 150 C files currently in the toplevel directory to separate, well-delimited subdirectories. No general objection (though some specific comments below). However I think it would be helpful if you could provide some descriptions of how your new subdirectories are defined. Otherwise the well-delimited bit is largely in your head and future new files aren't likely to respect it except by accident :-) Header files would be moved for now in include/, preparing for subsequent reorganization of headers. Just in include/, or in include/qemu/ ? (IIRC Anthony was hoping to only move cleaned-up headers in there?) Usually the files would keep their names, but I loathe names starting with qemu-* so I took the occasion to rename those. This does not touch the hw/ directory, which is its own mess and worth a separate discussion. Cleaning it up may require introducing more CONFIG_* symbols and moving stuff to libhw whenever possible (for example if we want all NICs in hw/net, all RTCs in hw/rtc, etc. perhaps with some exceptions for USB). Opinions, flames, stop this guys are welcome as usual. Paolo block: aes.c aio.c async.c block.c blockjob.c (with plans to move it in sysemu/block) nbd.c qemu-progress.c block/progress.c This should go in util/, surely? block/coroutine: coroutine-gthread.c block/coroutine/gthread.c coroutine-sigaltstack.c block/coroutine/sigaltstack.c coroutine-ucontext.cblock/coroutine/ucontext.c coroutine-win32.c block/coroutine/win32.c qemu-coroutine-io.c block/coroutine/io.c qemu-coroutine-lock.c block/coroutine/lock.c qemu-coroutine-sleep.c block/coroutine/sleep.c qemu-coroutine.cblock/coroutine/coroutine.c If this is accompanied by saying no more use of coroutines outside the block drivers then I'm cool with that. Otherwise it's not really the right place. block/drivers: block/blkdebug.c block/blkverify.c block/bochs.c block/cloop.c block/cow.c block/curl.c block/dmg.c block/iscsi.c block/mirror.c block/nbd.c block/parallels.c block/qcow.c block/qcow2-cache.c block/qcow2-cluster.c block/qcow2-refcount.c block/qcow2-snapshot.c block/qcow2.c block/qed-check.c block/qed-cluster.c block/qed-gencb.c block/qed-l2-cache.c block/qed-table.c block/qed.c block/raw-posix.c block/raw-win32.c block/raw.c block/rbd.c block/sheepdog.c block/vdi.c block/vmdk.c block/vpc.c block/vvfat.c linux-aio.c posix-aio-compat.c exec: cpu-exec.c disas.c exec.c gdbstub.c tci.c (note: TCI can't go in tcg/ for licensing reasons) More to the point, it shouldn't go in tcg/ because it's not a TCG backend -- this is the interpreter part. translate-all.c hw: hw/dma.chw/i8257.c dma-helpers.c hw/dma.c libdis: alpha-dis.c libdis/alpha.c arm-dis.c libdis/arm.c cris-dis.c libdis/cris.c hppa-dis.c libdis/hppa.c i386-dis.c libdis/i386.c ia64-dis.c libdis/ia64.c lm32-dis.c libdis/lm32.c m68k-dis.c libdis/m68k.c microblaze-dis.clibdis/microblaze.c mips-dis.c libdis/mips.c ppc-dis.c libdis/ppc.c s390-dis.c libdis/s390.c sh4-dis.c libdis/sh4.c sparc-dis.c libdis/sparc.c tci-dis.c libdis/tci.c net: net.c qapi: error.c qga: qemu-ga.c qga/main.c qobject: json-lexer.c json-parser.c json-streamer.c qbool.c qdict.c qerror.c qfloat.c qint.c qjson.c qlist.c qstring.c sysemu: So, sysemu.h is one of those dumping-ground header files. What's the dividing line that means a file goes into sysemu/ and not somewhere else? arch_init.c balloon.c cpus.c cputlb.c cursor.c device_tree.c dump-stub.c dump.c ioport.c kvm-all.c kvm-stub.c memory.c memory_mapping-stub.c memory_mapping.c os-posix.c os-win32.c pflib.c qemu-error.csysemu/error.c qemu-seccomp.c sysemu/seccomp.c qtest.c vl.c While we're at it is there some less bonkers name than 'vl.c' for the system emulator main file? xen-all.c xen-mapcache.c xen-stub.c qemu-options.hx sysemu/block: block/stream.c blockdev.c sysemu/bt: bt-host.c sysemu/bt/host.c bt-vhci.c sysemu/bt/vhci.c sysemu/char: qemu-char.c sysemu/char/chardev.c qemu-sockets.c sysemu/char/sockets.c spice-qemu-char.c sysemu/char/spice.c sysemu/migration: block-migration.c migration/block.c buffered_file.c migration-exec.c migration-fd.c migration-tcp.c migration-unix.c migration.c page_cache.c
Re: [Qemu-devel] directory hierarchy
On Fri, 14 Sep 2012 15:17:52 +0200 Paolo Bonzini pbonz...@redhat.com wrote: Hi all, here is a proposal for moving around 150 C files currently in the toplevel directory to separate, well-delimited subdirectories. Header files would be moved for now in include/, preparing for subsequent reorganization of headers. That would be really nice! A few comments below. Usually the files would keep their names, but I loathe names starting with qemu-* so I took the occasion to rename those. This does not touch the hw/ directory, which is its own mess and worth a separate discussion. Cleaning it up may require introducing more CONFIG_* symbols and moving stuff to libhw whenever possible (for example if we want all NICs in hw/net, all RTCs in hw/rtc, etc. perhaps with some exceptions for USB). Opinions, flames, stop this guys are welcome as usual. Paolo block: aes.c aio.c async.c block.c blockjob.c (with plans to move it in sysemu/block) nbd.c qemu-progress.c block/progress.c block/coroutine: coroutine-gthread.c block/coroutine/gthread.c coroutine-sigaltstack.c block/coroutine/sigaltstack.c coroutine-ucontext.cblock/coroutine/ucontext.c coroutine-win32.c block/coroutine/win32.c qemu-coroutine-io.c block/coroutine/io.c qemu-coroutine-lock.c block/coroutine/lock.c qemu-coroutine-sleep.c block/coroutine/sleep.c qemu-coroutine.cblock/coroutine/coroutine.c block/drivers: block/blkdebug.c block/blkverify.c block/bochs.c block/cloop.c block/cow.c block/curl.c block/dmg.c block/iscsi.c block/mirror.c block/nbd.c block/parallels.c block/qcow.c block/qcow2-cache.c block/qcow2-cluster.c block/qcow2-refcount.c block/qcow2-snapshot.c block/qcow2.c block/qed-check.c block/qed-cluster.c block/qed-gencb.c block/qed-l2-cache.c block/qed-table.c block/qed.c block/raw-posix.c block/raw-win32.c block/raw.c block/rbd.c block/sheepdog.c block/vdi.c block/vmdk.c block/vpc.c block/vvfat.c linux-aio.c posix-aio-compat.c exec: cpu-exec.c disas.c exec.c gdbstub.c tci.c (note: TCI can't go in tcg/ for licensing reasons) translate-all.c hw: hw/dma.chw/i8257.c dma-helpers.c hw/dma.c libdis: alpha-dis.c libdis/alpha.c arm-dis.c libdis/arm.c cris-dis.c libdis/cris.c hppa-dis.c libdis/hppa.c i386-dis.c libdis/i386.c ia64-dis.c libdis/ia64.c lm32-dis.c libdis/lm32.c m68k-dis.c libdis/m68k.c microblaze-dis.clibdis/microblaze.c mips-dis.c libdis/mips.c ppc-dis.c libdis/ppc.c s390-dis.c libdis/s390.c sh4-dis.c libdis/sh4.c sparc-dis.c libdis/sparc.c tci-dis.c libdis/tci.c net: net.c qapi: error.c error.c isn't tied to a subsystem, it's really qemu wide. If it must reside in dir (ie. it can't be in the top dir), then I'd suggest to put it in qmp. qga: qemu-ga.c qga/main.c qga/ has several files today, not only qga/main.c. I'd suggest naming the directory qemu-ga and moving everything there, but it's better to double check with Michael. qobject: json-lexer.c json-parser.c json-streamer.c qbool.c qdict.c qerror.c qfloat.c qint.c qjson.c qlist.c qstring.c I'd move json-* files to qmp/. sysemu: arch_init.c balloon.c cpus.c cputlb.c cursor.c device_tree.c dump-stub.c dump.c ioport.c kvm-all.c kvm-stub.c memory.c memory_mapping-stub.c memory_mapping.c os-posix.c os-win32.c pflib.c qemu-error.csysemu/error.c qemu-seccomp.c sysemu/seccomp.c qtest.c vl.c xen-all.c xen-mapcache.c xen-stub.c qemu-options.hx sysemu/block: block/stream.c blockdev.c sysemu/bt: bt-host.c sysemu/bt/host.c bt-vhci.c sysemu/bt/vhci.c sysemu/char: qemu-char.c sysemu/char/chardev.c qemu-sockets.c sysemu/char/sockets.c spice-qemu-char.c sysemu/char/spice.c sysemu/migration: block-migration.c migration/block.c buffered_file.c migration-exec.c migration-fd.c migration-tcp.c migration-unix.c migration.c page_cache.c savevm.c sysemu/monitor: hmp.c monitor.c qmp.c readline.c hmp-commands.hx qmp-commands.hx Please, move qmp.c qmp-commands.hx to qmp/. tcg: tcg-runtime.c tcg/runtime.c tools: cmd.c qemu-bridge-helper.c qemu-img.c qemu-img-cmds.hx qemu-io.c qemu-nbd.c qemu-tool.c tools/stub.c ui: console.c input.c user: qemu-user.c user/stub.c thunk.c user-exec.c user/cpu-exec.c util: acl.c bitmap.c bitops.c cache-utils.c
Re: [Qemu-devel] directory hierarchy
On Fri, Sep 14, 2012 at 03:17:52PM +0200, Paolo Bonzini wrote: Hi all, here is a proposal for moving around 150 C files currently in the toplevel directory to separate, well-delimited subdirectories. Header files would be moved for now in include/, preparing for subsequent reorganization of headers. I tend to view usage of a separate 'include/' subdirectory as a location for public facing header files. For internal header files, IMHO, its nicer to just have them alongside the .c file which has the corresponding implementation. I know QEMU has traditionally been a bit wierd having giant header files containing decls that are then implemented across a whole set of source files. Perhaps it is worthwhile to focus on santizing the headers rather than moving them elsewhere where there's even less incentive to keep header + source filenames aligned. Usually the files would keep their names, but I loathe names starting with qemu-* so I took the occasion to rename those. Heh, I would have suggested the opposite - use a 'qemu-' prefix on every single file, mostly so that you avoid the confusion where a source-local header file happens to have same name as a public header file in /usr/include. This does not touch the hw/ directory, which is its own mess and worth a separate discussion. Cleaning it up may require introducing more CONFIG_* symbols and moving stuff to libhw whenever possible (for example if we want all NICs in hw/net, all RTCs in hw/rtc, etc. perhaps with some exceptions for USB). Opinions, flames, stop this guys are welcome as usual. I appauld your amibition to modularize the source tree layout more. Even if you disagree with my POV on the issues above, it would be an improvement. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] directory hierarchy
On 14 September 2012 14:17, Paolo Bonzini pbonz...@redhat.com wrote: here is a proposal for moving around 150 C files currently in the toplevel directory to separate, well-delimited subdirectories. ...oh, and it would be good to be sure we've fixed all the problems with dependencies that tend to cause 'make' to fail to DTRT going backwards and forwards across a file-move commit, before we move everything around... -- PMM
Re: [Qemu-devel] directory hierarchy
Il 14/09/2012 15:36, Peter Maydell ha scritto: On 14 September 2012 14:17, Paolo Bonzini pbonz...@redhat.com wrote: here is a proposal for moving around 150 C files currently in the toplevel directory to separate, well-delimited subdirectories. No general objection (though some specific comments below). However I think it would be helpful if you could provide some descriptions of how your new subdirectories are defined. Otherwise the well-delimited bit is largely in your head and future new files aren't likely to respect it except by accident :-) Good question. I just tried to use some taste, so well-delimited is a bit of a lie. I mostly care that sysemu/, tools/, qga/ and user/ are well-delimited, i.e. executables do not have sources from other executables' directories, and similarly common/ is just for emulators. Header files would be moved for now in include/, preparing for subsequent reorganization of headers. Just in include/, or in include/qemu/ ? (IIRC Anthony was hoping to only move cleaned-up headers in there?) I dislike include/qemu, for the same reason I dislike qemu-*. :) Moving to include/ would be to clean up the top-level directory, withour touching the source code. If something can be moved directly to one of the new source directories, that's also fine but I don't have high hopes. Usually the files would keep their names, but I loathe names starting with qemu-* so I took the occasion to rename those. This does not touch the hw/ directory, which is its own mess and worth a separate discussion. Cleaning it up may require introducing more CONFIG_* symbols and moving stuff to libhw whenever possible (for example if we want all NICs in hw/net, all RTCs in hw/rtc, etc. perhaps with some exceptions for USB). Opinions, flames, stop this guys are welcome as usual. Paolo block: qemu-progress.c block/progress.c This should go in util/, surely? Yes. I considered tools/ but right now it is in block-obj-y and I haven't yet checked if the emulators depend on it. But util/ is probably better. block/coroutine: If this is accompanied by saying no more use of coroutines outside the block drivers then I'm cool with that. Otherwise it's not really the right place. There is no use right now outside the block drivers or the block jobs. So s/more//. Let's say this would discourage using coroutines outside the block drivers, but if somebody has a really good reason it would move to util/. It's a two-line change. exec: cpu-exec.c disas.c exec.c gdbstub.c tci.c (note: TCI can't go in tcg/ for licensing reasons) More to the point, it shouldn't go in tcg/ because it's not a TCG backend -- this is the interpreter part. Ok. sysemu: So, sysemu.h is one of those dumping-ground header files. What's the dividing line that means a file goes into sysemu/ and not somewhere else? It must only be used by the system emulators. vl.c While we're at it is there some less bonkers name than 'vl.c' for the system emulator main file? I was about to do that, but I like to keep the historical name if it's just a one-off... Just some respect for Fabrice. :) tcg: tcg-runtime.c tcg/runtime.c This is kind of breaking an existing division, where tcg/ contains the code generator, and code outside tcg provides the execution environment for that generated code. In particular tcg-runtime.c is the QEMU implementation of a bunch of runtime functions and in theory some other runtime that embedded TCG could provide its own runtime helpers. (In practice TCG isn't as neatly separated from the rest of QEMU as you might like, if for instance you wanted to do TCG unit tests.) If that would mean putting it in exec/, that would be fine. util: main-loop.c This file is either misnamed or shouldn't be in util/... It implements a generic main loop based on select. It is used by system emulators, qemu-io and qemu-nbd. Paolo
Re: [Qemu-devel] directory hierarchy
Il 14/09/2012 15:48, Peter Maydell ha scritto: here is a proposal for moving around 150 C files currently in the toplevel directory to separate, well-delimited subdirectories. ...oh, and it would be good to be sure we've fixed all the problems with dependencies that tend to cause 'make' to fail to DTRT going backwards and forwards across a file-move commit, before we move everything around... I think we have, at least I haven't seen complaints recently. :) Paolo
Re: [Qemu-devel] directory hierarchy
Il 14/09/2012 15:47, Daniel P. Berrange ha scritto: On Fri, Sep 14, 2012 at 03:17:52PM +0200, Paolo Bonzini wrote: Hi all, here is a proposal for moving around 150 C files currently in the toplevel directory to separate, well-delimited subdirectories. Header files would be moved for now in include/, preparing for subsequent reorganization of headers. I tend to view usage of a separate 'include/' subdirectory as a location for public facing header files. For internal header files, IMHO, its nicer to just have them alongside the .c file which has the corresponding implementation. Yes, me too, but unfortunately almost nothing follows this scheme in QEMU. Probably the hw/ files do, but I'm not touching those with a pole. Usually the files would keep their names, but I loathe names starting with qemu-* so I took the occasion to rename those. Heh, I would have suggested the opposite - use a 'qemu-' prefix on every single file, mostly so that you avoid the confusion where a source-local header file happens to have same name as a public header file in /usr/include. Note the above quote is about C files, not headers. For headers, I would solve the confusion by moving them all in subdirectories of include/, but not yet. I want to keep source files 100% unchanged for now. I appauld your amibition to modularize the source tree layout more. Even if you disagree with my POV on the issues above, it would be an improvement. Oh, on a fresh project I'd agree a lot. Just trying to do things piecewise. Paolo
Re: [Qemu-devel] directory hierarchy
On 14 September 2012 14:55, Paolo Bonzini pbonz...@redhat.com wrote: Il 14/09/2012 15:48, Peter Maydell ha scritto: ...oh, and it would be good to be sure we've fixed all the problems with dependencies that tend to cause 'make' to fail to DTRT going backwards and forwards across a file-move commit, before we move everything around... I think we have, at least I haven't seen complaints recently. :) I think people have just stopped bothering to complain. I'm pretty sure I saw breakage around commit 58f9b98f for example. -- PMM
Re: [Qemu-devel] directory hierarchy
Il 14/09/2012 15:44, Luiz Capitulino ha scritto: qapi: error.c error.c isn't tied to a subsystem, it's really qemu wide. If it must reside in dir (ie. it can't be in the top dir), then I'd suggest to put it in qmp. It's either qapi/ or util/. I'd rather avoid util/ as a dumping ground, and error.c (and propagation) seemed quite central to QAPI. But I can change. There is no qmp/. There is qapi/, qobject/ and sysemu/monitor. Since Anthony mentioned that QOM and QAPI are used together with QObject, but not tied, putting the JSON stuff in qobject/ made sense (qga uses it). Renaming qobject/ to qmp/ makes sense, I can do that. However, it should be clear that qmp/ is for stuff shared by the emulators and qemu-ga, so qmp.c and qmp-commands.hx do not belong in there. Paolo
Re: [Qemu-devel] directory hierarchy
Am 14.09.2012 15:17, schrieb Paolo Bonzini: Hi all, here is a proposal for moving around 150 C files currently in the toplevel directory to separate, well-delimited subdirectories. Header files would be moved for now in include/, preparing for subsequent reorganization of headers. Usually the files would keep their names, but I loathe names starting with qemu-* so I took the occasion to rename those. This does not touch the hw/ directory, which is its own mess and worth a separate discussion. Cleaning it up may require introducing more CONFIG_* symbols and moving stuff to libhw whenever possible (for example if we want all NICs in hw/net, all RTCs in hw/rtc, etc. perhaps with some exceptions for USB). Opinions, flames, stop this guys are welcome as usual. Paolo I really appreciate your proposal for a cleaner directory hierarchy. Here are some more ideas: * Move the target-xxx directories (currently 15) to target/xxx. * Add host/xxx for host specific files (xxx = posix, wxx). Here the currently used win32 might be replaced by either wxx or by win as most of it also applies to w64. An alternative solution would add host specific subdirectories to include/qemu and util. * Move machine implementations (code which calls machine_init) to the respective architecture directories (hw/arm, ...). Meanwhile we have more than 50 machine implementations in hw. We could also replace hw/alpha, hw/arm, hw/cris, ... to hw/arch/alpha and so on. * Move hardware implementations which are architecture specific to the architecture directories. This is sometimes less obvious than the machine implementations. Stefan
Re: [Qemu-devel] directory hierarchy
Am 14.09.2012 15:17, schrieb Paolo Bonzini: Hi all, here is a proposal for moving around 150 C files currently in the toplevel directory to separate, well-delimited subdirectories. Header files would be moved for now in include/, preparing for subsequent reorganization of headers. Usually the files would keep their names, but I loathe names starting with qemu-* so I took the occasion to rename those. This does not touch the hw/ directory, which is its own mess and worth a separate discussion. Cleaning it up may require introducing more CONFIG_* symbols and moving stuff to libhw whenever possible (for example if we want all NICs in hw/net, all RTCs in hw/rtc, etc. perhaps with some exceptions for USB). Opinions, flames, stop this guys are welcome as usual. Cleaning up the main directory is probably a good idea. However, we should be aware that renaming comes with a cost: Some git commands on a single file need additional options (git log --follow) to work well across renames, for others you need to know the old name in the commit you're looking at (I'm thinking of git blame here). So let's try hard to move files only when we are very sure that they are in the right place afterwards, so that we don't have the pain twice. Paolo block: aes.c aio.c async.c Certainly not, BHs are used all over qemu. block.c blockjob.c (with plans to move it in sysemu/block) I'm not sure if sysemu/block makes sense. But if it does, it shouldn't contain things that in theory are usable by tools as well. I think block jobs could make sense for qemu-img, they are basically the live versions of what qemu-img duplicates. If anything, blockjob.c could become generic infrastructure, because as we noticed a while ago, there's not much that ties them to block devices. nbd.c qemu-progress.c block/progress.c Probably not block specific either. block/coroutine: coroutine-gthread.c block/coroutine/gthread.c coroutine-sigaltstack.c block/coroutine/sigaltstack.c coroutine-ucontext.cblock/coroutine/ucontext.c coroutine-win32.c block/coroutine/win32.c qemu-coroutine-io.c block/coroutine/io.c qemu-coroutine-lock.c block/coroutine/lock.c qemu-coroutine-sleep.c block/coroutine/sleep.c qemu-coroutine.cblock/coroutine/coroutine.c Coroutines should be top-level, virtio-9p uses them. block/drivers: block/blkdebug.c block/blkverify.c block/bochs.c block/cloop.c block/cow.c block/curl.c block/dmg.c block/iscsi.c block/mirror.c block/nbd.c block/parallels.c block/qcow.c block/qcow2-cache.c block/qcow2-cluster.c block/qcow2-refcount.c block/qcow2-snapshot.c block/qcow2.c block/qed-check.c block/qed-cluster.c block/qed-gencb.c block/qed-l2-cache.c block/qed-table.c block/qed.c block/raw-posix.c block/raw-win32.c block/raw.c block/rbd.c block/sheepdog.c block/vdi.c block/vmdk.c block/vpc.c block/vvfat.c linux-aio.c posix-aio-compat.c We could consider subdirectories for qcow2, qed and raw-posix. I'm not convinced that it would be a good idea, but neither that it would be a bad one. I just know that I don't want to move them more than once. :-) sysemu/block: block/stream.c blockdev.c See above, I think stream.c should stay where it is; not sure if blockdev.c needs its own subdirectory. sysemu/bt: bt-host.c sysemu/bt/host.c bt-vhci.c sysemu/bt/vhci.c sysemu/char: qemu-char.c sysemu/char/chardev.c qemu-sockets.c sysemu/char/sockets.c spice-qemu-char.c sysemu/char/spice.c sysemu/migration: block-migration.c migration/block.c buffered_file.c migration-exec.c migration-fd.c migration-tcp.c migration-unix.c migration.c page_cache.c savevm.c sysemu/monitor: hmp.c monitor.c qmp.c readline.c hmp-commands.hx qmp-commands.hx tcg: tcg-runtime.c tcg/runtime.c tools: cmd.c Rename to something that makes it clearer that it's part of qemu-io? Kevin
Re: [Qemu-devel] directory hierarchy
Il 14/09/2012 16:37, Stefan Weil ha scritto: Here are some more ideas: * Move the target-xxx directories (currently 15) to target/xxx. Yes, of course. * Add host/xxx for host specific files (xxx = posix, wxx). Here the currently used win32 might be replaced by either wxx or by win as most of it also applies to w64. An alternative solution would add host specific subdirectories to include/qemu and util. This makes sense, though it becomes more problematic as the host files are scattered around the tree. * Move machine implementations (code which calls machine_init) to the respective architecture directories (hw/arm, ...). Meanwhile we have more than 50 machine implementations in hw. We could also replace hw/alpha, hw/arm, hw/cris, ... to hw/arch/alpha and so on. * Move hardware implementations which are architecture specific to the architecture directories. This is sometimes less obvious than the machine implementations. This I left out purposedly. :) Paolo
Re: [Qemu-devel] directory hierarchy
Il 14/09/2012 18:09, Kevin Wolf ha scritto: Cleaning up the main directory is probably a good idea. However, we should be aware that renaming comes with a cost: Some git commands on a single file need additional options (git log --follow) to work well across renames, for others you need to know the old name in the commit you're looking at (I'm thinking of git blame here). I think there was some magic for git blame. So let's try hard to move files only when we are very sure that they are in the right place afterwards, so that we don't have the pain twice. Yes, and that's why I'm leaving hw/ aside. The only problem is include files, which might be moved twice if they are further refactored (first in include/, and later to subsystem-specific subdirectories). I'll try however to look for header files that can be moved to one of the new subdirectories, and move them there. Paolo
Re: [Qemu-devel] directory hierarchy
On Fri, Sep 14, 2012 at 1:17 PM, Paolo Bonzini pbonz...@redhat.com wrote: Hi all, here is a proposal for moving around 150 C files currently in the toplevel directory to separate, well-delimited subdirectories. Header files would be moved for now in include/, preparing for subsequent reorganization of headers. Usually the files would keep their names, but I loathe names starting with qemu-* so I took the occasion to rename those. This does not touch the hw/ directory, which is its own mess and worth a separate discussion. Cleaning it up may require introducing more CONFIG_* symbols and moving stuff to libhw whenever possible (for example if we want all NICs in hw/net, all RTCs in hw/rtc, etc. perhaps with some exceptions for USB). Opinions, flames, stop this guys are welcome as usual. Good idea. Paolo block: aes.c aio.c async.c block.c blockjob.c (with plans to move it in sysemu/block) nbd.c qemu-progress.c block/progress.c block/coroutine: coroutine-gthread.c block/coroutine/gthread.c coroutine-sigaltstack.c block/coroutine/sigaltstack.c coroutine-ucontext.cblock/coroutine/ucontext.c coroutine-win32.c block/coroutine/win32.c qemu-coroutine-io.c block/coroutine/io.c qemu-coroutine-lock.c block/coroutine/lock.c qemu-coroutine-sleep.c block/coroutine/sleep.c qemu-coroutine.cblock/coroutine/coroutine.c block/drivers: block/blkdebug.c block/blkverify.c block/bochs.c block/cloop.c block/cow.c block/curl.c block/dmg.c block/iscsi.c block/mirror.c block/nbd.c block/parallels.c block/qcow.c block/qcow2-cache.c block/qcow2-cluster.c block/qcow2-refcount.c block/qcow2-snapshot.c block/qcow2.c block/qed-check.c block/qed-cluster.c block/qed-gencb.c block/qed-l2-cache.c block/qed-table.c block/qed.c block/raw-posix.c block/raw-win32.c block/raw.c block/rbd.c block/sheepdog.c block/vdi.c block/vmdk.c block/vpc.c block/vvfat.c linux-aio.c posix-aio-compat.c exec: These files need cleanup so that TCG code gets into tcg/. Maybe also TB and CPUTLB handling. cpu-exec.c disas.c exec.c gdbstub.c tci.c (note: TCI can't go in tcg/ for licensing reasons) The directory organization should not be affected by licensing issues, it's licenses of each file that counts. We could create a new directory and move code from TCG to that. translate-all.c hw: hw/dma.chw/i8257.c dma-helpers.c hw/dma.c libdis: alpha-dis.c libdis/alpha.c arm-dis.c libdis/arm.c cris-dis.c libdis/cris.c hppa-dis.c libdis/hppa.c i386-dis.c libdis/i386.c ia64-dis.c libdis/ia64.c lm32-dis.c libdis/lm32.c m68k-dis.c libdis/m68k.c microblaze-dis.clibdis/microblaze.c mips-dis.c libdis/mips.c ppc-dis.c libdis/ppc.c s390-dis.c libdis/s390.c sh4-dis.c libdis/sh4.c sparc-dis.c libdis/sparc.c tci-dis.c libdis/tci.c net: net.c qapi: error.c qga: qemu-ga.c qga/main.c qobject: json-lexer.c json-parser.c json-streamer.c qbool.c qdict.c qerror.c qfloat.c qint.c qjson.c qlist.c qstring.c sysemu: arch_init.c balloon.c cpus.c cputlb.c cursor.c device_tree.c dump-stub.c dump.c ioport.c kvm-all.c kvm-stub.c How about kvm and xen as top level directories? memory.c memory_mapping-stub.c memory_mapping.c os-posix.c os-win32.c pflib.c qemu-error.csysemu/error.c qemu-seccomp.c sysemu/seccomp.c qtest.c vl.c xen-all.c xen-mapcache.c xen-stub.c qemu-options.hx sysemu/block: This distinction is not so clear to me. For example, why do block/ and qobject/ reside in the top level? block/stream.c blockdev.c sysemu/bt: bt-host.c sysemu/bt/host.c bt-vhci.c sysemu/bt/vhci.c sysemu/char: qemu-char.c sysemu/char/chardev.c qemu-sockets.c sysemu/char/sockets.c spice-qemu-char.c sysemu/char/spice.c sysemu/migration: block-migration.c migration/block.c buffered_file.c migration-exec.c migration-fd.c migration-tcp.c migration-unix.c migration.c page_cache.c savevm.c sysemu/monitor: hmp.c monitor.c qmp.c readline.c hmp-commands.hx qmp-commands.hx I think audio and maybe net could also fit here as subdirectories of sysemu. tcg: tcg-runtime.c tcg/runtime.c tools: cmd.c qemu-bridge-helper.c qemu-img.c qemu-img-cmds.hx qemu-io.c qemu-nbd.c qemu-tool.c tools/stub.c ui: console.c input.c user: qemu-user.c user/stub.c thunk.c user-exec.c user/cpu-exec.c Also
Re: [Qemu-devel] directory hierarchy
Il 14/09/2012 21:51, Blue Swirl ha scritto: On Fri, Sep 14, 2012 at 1:17 PM, Paolo Bonzini pbonz...@redhat.com wrote: Hi all, here is a proposal for moving around 150 C files currently in the toplevel directory to separate, well-delimited subdirectories. Header files would be moved for now in include/, preparing for subsequent reorganization of headers. Usually the files would keep their names, but I loathe names starting with qemu-* so I took the occasion to rename those. This does not touch the hw/ directory, which is its own mess and worth a separate discussion. Cleaning it up may require introducing more CONFIG_* symbols and moving stuff to libhw whenever possible (for example if we want all NICs in hw/net, all RTCs in hw/rtc, etc. perhaps with some exceptions for USB). Opinions, flames, stop this guys are welcome as usual. Good idea. exec: These files need cleanup so that TCG code gets into tcg/. Maybe also TB and CPUTLB handling. cpu-exec.c disas.c exec.c gdbstub.c tci.c (note: TCI can't go in tcg/ for licensing reasons) The directory organization should not be affected by licensing issues, it's licenses of each file that counts. We could create a new directory and move code from TCG to that. exec/ is basically the common parts of user- and system-mode emulation. It's unrelated to separating TCG from other accelerators. translate-all.c sysemu: arch_init.c balloon.c cpus.c cputlb.c cursor.c device_tree.c dump-stub.c dump.c ioport.c kvm-all.c kvm-stub.c How about kvm and xen as top level directories? Note sure, it's just 2-3 files each for now. memory.c memory_mapping-stub.c memory_mapping.c os-posix.c os-win32.c pflib.c qemu-error.csysemu/error.c qemu-seccomp.c sysemu/seccomp.c qtest.c vl.c xen-all.c xen-mapcache.c xen-stub.c qemu-options.hx sysemu/block: This distinction is not so clear to me. For example, why do block/ and qobject/ reside in the top level? Because they are used by tools. sysemu/ is not going to be used by tools nor user-mode emulation. block/stream.c blockdev.c sysemu/bt: bt-host.c sysemu/bt/host.c bt-vhci.c sysemu/bt/vhci.c sysemu/char: qemu-char.c sysemu/char/chardev.c qemu-sockets.c sysemu/char/sockets.c spice-qemu-char.c sysemu/char/spice.c sysemu/migration: block-migration.c migration/block.c buffered_file.c migration-exec.c migration-fd.c migration-tcp.c migration-unix.c migration.c page_cache.c savevm.c sysemu/monitor: hmp.c monitor.c qmp.c readline.c hmp-commands.hx qmp-commands.hx I think audio and maybe net could also fit here as subdirectories of sysemu. Yes, also ui/, fsdev/, slirp/, but I omitted those for simplicity. Paolo
