[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: virtiofsd: Where should it live?
From: |
Markus Armbruster |
Subject: |
Re: virtiofsd: Where should it live? |
Date: |
Wed, 04 Dec 2019 08:43:29 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) |
Daniel P. Berrangé <address@hidden> writes:
> On Tue, Dec 03, 2019 at 11:06:44AM +0000, Peter Maydell wrote:
>> On Tue, 3 Dec 2019 at 10:53, Dr. David Alan Gilbert <address@hidden> wrote:
>> >
>> > We seem to be coming to the conclusion something that:
>> >
>> > a) It should live in the qemu tree
>> > b) It shouldn't live under contrib
>> > c) We'll create a new top level, i.e. 'daemons'
>> > d) virtiofsd will be daemons/virtiofsd
>> >
>> > Now, somethings I'm less clear on:
>> > e) What else would move into daemons? It was suggested
>> > that if we've got virtiofsd in there, then we should move
>> > libvhost-user - which I understand, but then it's not a
>> > 'daemons'.
>> > Are there any otehr daemons that should move?
>>
>> I like the idea of a new top level directory, but I think
>> 'daemons' is a bit too specific -- for instance it seems to
>> me that qemu-img would be sensible to move out of the root,
>> and that's not a daemon.
>
> Do we really need an extra directory level ?
+1
> IIUC, the main point against having $GIT_ROOT/virtiofsd is that
> the root of our repo is quite cluttered already.
>
> Rather than trying to create a multi-level hierarchy which adds
> a debate around naming, why not address the clutter by moving
> *ALL* the .c/.h files out of the root so that we have a flatter
> tree:
>
> $GITROOT
> +- qemu-system
> | +- vl.c
> | +- ...most other files...
Sounds good to me.
> +- qemu-img
> | +- qemu-img.c
Perhaps this one can all go into existing block/, similar to how
pr-manager-helper.c is in scsi/, and virtfs-proxy-helper.c is in fsdev/.
Up to the block maintainers, of course.
> +- qemu-nbd
> | +- qemu-nbd.c
block/ or nbd/?
> +- qemu-io
> | +- qemu-io.c
> | +- qemu-io-cmds.c
block/?
> +- qemu-bridge-helper
net/?
> | ...
> +- qemu-edid
Has its own MAINTAINERS section, together with hw/display/edit* and
include/hw/display/edid.h. I'm not sure moving it hw/display/ is a good
idea. Gerd?
> +- qemu-keymap
Not covered by MAINTAINERS. scripts/get_maintainer.pl --git-blame
points to Gerd.
> +- qga (already exists)
Yes.
> Then we can add virtiofsd and other programs at the root with no big
> issue.
We don't *have* to put each program into its own directory. Simple ones
could also share one. We just need a directory name.