Daniel P. Berrangé <berra...@redhat.com> 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 <dgilb...@redhat.com> >> 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.
