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. There's also precedence for putting such programs into their subsystem's sub-directory: fsdev/virtfs-proxy-helper, scsi/pr-manager-helper.
