From: Paolo Bonzini <pbonzini@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] directory hierarchy
Date: Fri, 14 Sep 2012 15:53:36 +0200 [thread overview]
Message-ID: <505336E0.6010509@redhat.com> (raw)
In-Reply-To: <CAFEAcA_1UBXu-OHWyO2sdyPSgPuhO2n2pHbkwU19T52a9KDvsg@mail.gmail.com>
Il 14/09/2012 15:36, Peter Maydell ha scritto:
> On 14 September 2012 14:17, Paolo Bonzini <pbonzini@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 guy"s 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
next prev parent reply other threads:[~2012-09-14 13:53 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 [this message]
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
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=505336E0.6010509@redhat.com \
--to=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.