qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] directory hierarchy


From: Kevin Wolf
Subject: Re: [Qemu-devel] directory hierarchy
Date: Fri, 14 Sep 2012 18:09:20 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0

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 guy"s 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.c            block/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.c                block/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



reply via email to

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