* Markus Armbruster (arm...@redhat.com) wrote: > Thomas Huth <th...@redhat.com> writes: > > > On 02/12/2019 13.56, Markus Armbruster wrote: > >> Peter Maydell <peter.mayd...@linaro.org> writes: > >> > >>> On Tue, 26 Nov 2019 at 12:15, Dr. David Alan Gilbert > >>> <dgilb...@redhat.com> wrote: > >>>> > >>>> * Daniel P. Berrangé (berra...@redhat.com) wrote: > >>>>> My main objection to 'contrib/' is actually the perceived notions > >>>>> about what the contrib directory is for. When I see 'contrib/' > >>>>> code in either QEMU, or other open source projects, my general > >>>>> impression is that this is largely unsupported code which is just > >>>>> there as it might be interesting to someone, and doesn't typically > >>>>> get much ongoing dev attention. > >>> > >>>>> virtiofsd is definitely different as it is intended to be a > >>>>> fully production quality supported tool with active dev into > >>>>> the future IIUC. > >>>>> > >>>>> IOW, if we did decide we want it in QEMU, then instead of > >>>>> '$GIT/contrib/virtiofsd', I'd prefer to see '$GIT/virtiofsd'. > >>>> > >>>> I'm not sure it deserves a new top level for such a specific tool. > >>> > >>> Maybe, but I think I agree with Daniel that 'contrib/' is > >>> probably not the right place for it if it's something that > >>> we care about supporting. 'contrib' to me is "bucket of stuff > >>> that we didn't really feel strongly we wanted to reject but > >>> which is probably random special-cases or other obscure > >>> stuff, don't bother looking in here and don't assume it's > >>> going to work either". > >> > >> Agree. > >> > >> We have source for several separate programs in the root directory > >> already: qemu-bridge-helper, qemu-edid, qemu-img, qemu-io, qemu-nbd, > >> qemu-keymap, qemu-seccomp, qemu-ga. Just a .c file when that suffixes, > >> else a subdirectory, except for qemu-io, which is two .c files in the > >> root, plus include/qemu-io.h. Putting virtiofsd/ there follows > >> qemu-ga's precedence. > > > > IMHO the root directory is still way too overcrowded. Maybe we should > > simply introduce a "tools" subdirectory? > > Maybe. In general, I prefer my source trees shallow.
I think I agree with Thomas that it should be in a subdirectory for all tools like that; creating virtiofsd at the top level feels wrong to me since it's just too specific. Someone please pick a name :-) > We've sucked at keeping new files out of the root that don't belong > there. Mending our ways going forward is just one half of the fix. The > other half is cleaning up the mess we made. It's been getting better over time mostly. We could lose qemu-bridge-helper.c into this new directory. Dave > The manual should be somewhere below docs/. > > Several .[ch] should be in a suitable subdirectory. > > $ git-ls-files | grep -v / | grep '\.[ch]$' > arch_init.c > balloon.c > block.c > blockdev-nbd.c > blockdev.c > blockjob.c > bootdevice.c > bt-host.c > bt-vhci.c > cpus-common.c > cpus.c > device-hotplug.c > device_tree.c > disas.c > dma-helpers.c > exec-vary.c > exec.c > gdbstub.c > ioport.c > iothread.c > job-qmp.c > job.c > memory.c > memory_ldst.inc.c > memory_mapping.c > module-common.c > os-posix.c > os-win32.c > qdev-monitor.c > qemu-bridge-helper.c > qemu-edid.c > qemu-img.c > qemu-io-cmds.c > qemu-io.c > qemu-keymap.c > qemu-nbd.c > qemu-options-wrapper.h > qemu-options.h > qemu-seccomp.c > qtest.c > replication.c > replication.h > thunk.c > tpm.c > vl.c -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
