On Mon, Nov 25, 2019 at 06:50:21PM +0000, Dr. David Alan Gilbert wrote: > Hi, > There's been quite a bit of discussion about where virtiofsd, our > implemenation of a virtiofs daemon, should live. I'd like to get > this settled now, because I'd like to tidy it up for the next > qemu cycle. > > For reference it's based on qemu's livhost-user+chunks of libfuse. > It can't live in libfuse because we change enough of the library > to break their ABI. It's C, and we've got ~100 patches - which > we can split into about 3 chunks. > > Some suggestions so far: > a) In contrib > This is my current working assumption; the main objection is it's > a bit big and pulls in a chunk of libfuse.
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. Parts that are fully supported & actively developed by projects usually live elsewhere like a src/ or lib/ or tools/ directory. This has kind of been the case with QEMU historically, with the vhost-user-blk, vhost-user-scsi not being real production quality implementations. Rather they are just technology demos to show what you might do. vhost-user-gpu/input blurred this boundary a bit as they're more supported tools, and so I'd argue contrib/ probably wasn't the right place for them either in hindsight. 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'. > b) In a submodule > > c) Just separate > > Your suggestions/ideas please. My preference is (a). What I'm wondering is just how much sharing / overlap of code and concepts and community operation there is going otbetween QEMU and virtiofsd. From the tech POV, IIUC, the main blocker it would need to be in QEMU is because it links to libvhost-user and we've not declared that to be a stable API for 3rd party linking. Personally I'm always biased towards self-contained apps being in their own repositories, rather than bundling too much stuff into one repo. You can see that in the way we've created independant git repos for any libvirt module that didn't need to be part of the main libvirt.git. To me the key benefit this gives is flexibility in approach. ie the app doesn't need to blindly follow every precedent that QEMU has set. It can instead take the most appropriate path for its needs. For example... It could use meson for its build system already. This would be good as builds will be done in a matter of seconds. For contributors it would be a much less daunting project to join as it wouldn't be lost in the firehose of other non-virtiofsd contributions on qemu-devel. It doesn't have to follow QEMU's 3-times a year release model, with 6 week long freeze periods. It can be more agile releasing 6 times a year with 1 week freezes if desired, I personally think tihs would be quite desirable for a young project like virtiofsd which is evolving rapidly as it would get new work available to users much more rapidly. It doesn't have to follow QEMU's API stability & deprecation policies. It could be more flexible in taking non-compatible changes, which again may be valuable for a young rapidly evolving app. Anyway to be clear, I'm not a contributor to virtiofsd, nor likely to be one in the future, so just consider this a personal POV. From QEMU's POV I don't think it'll matter whether virtiofsd in or out of QEMU git. It is more about the impact & burden QEMU's dev process & standards might impose on virtiofsd itself. I'm fine with whatever option above is chosen, with the only caveat being that if its in qemu.git, I don't think it belongs under contrib/ it should be a top level dir of its own. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|