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? Thomas
