qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] directory hierarchy
Date: Fri, 14 Sep 2012 18:09:20 +0200	[thread overview]
Message-ID: <505356B0.8050004@redhat.com> (raw)
In-Reply-To: <50532E80.5060905@redhat.com>

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

  parent reply	other threads:[~2012-09-14 16:09 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-14 13:17 [Qemu-devel] directory hierarchy Paolo Bonzini
2012-09-14 13:36 ` Peter Maydell
2012-09-14 13:53   ` Paolo Bonzini
2012-09-16 14:40     ` Anthony Liguori
2012-09-17  7:47       ` Paolo Bonzini
2012-09-14 13:44 ` Luiz Capitulino
2012-09-14 14:03   ` Paolo Bonzini
2012-09-14 13:47 ` Daniel P. Berrange
2012-09-14 13:57   ` Paolo Bonzini
2012-09-14 13:48 ` Peter Maydell
2012-09-14 13:55   ` Paolo Bonzini
2012-09-14 14:00     ` Peter Maydell
2012-09-14 14:37 ` Stefan Weil
2012-09-14 16:36   ` Paolo Bonzini
2012-09-14 16:09 ` Kevin Wolf [this message]
2012-09-14 16:45   ` Paolo Bonzini
2012-09-14 19:51 ` Blue Swirl
2012-09-14 21:28   ` Paolo Bonzini
2012-09-19 12:54   ` Avi Kivity
2012-09-19 19:57     ` Blue Swirl
2012-09-20 11:31       ` Avi Kivity
2012-09-22 13:15         ` Blue Swirl
2012-09-23  8:25           ` Avi Kivity
2012-09-23 16:07             ` Blue Swirl
2012-09-24  9:54               ` Avi Kivity
2012-09-16 14:44 ` Anthony Liguori
2012-09-17  7:52   ` Paolo Bonzini
2012-09-17 13:04     ` Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=505356B0.8050004@redhat.com \
    --to=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).