* Marc-André Lureau (marcandre.lur...@gmail.com) wrote: > Hi David > > On Mon, Nov 25, 2019 at 10:50 PM Dr. David Alan Gilbert > <dgilb...@redhat.com> 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 > > > > b) In a submodule > > > > c) Just separate > > > > Your suggestions/ideas please. My preference is (a). > > > > > It's more about code sharing and lifecycle. > > The project started in a separate repository, and the proposed patches > for qemu aren't a clean series. Reviewing it is harder than it should > be, as we have to review/accept the whole thing. > > As you said, it doesn't share much with qemu, but libvhost-user (which > we could quite easily copy or make standalone/submodule). > > Then it dumps code from libfuse that is questionnable (showing age) > and often redundant with facilities provided by either glib, qemu > utils etc.
The libfuse code is pretty much upto date. > Is vhost-user-fs (the qemu device) going to have a strong relation > with virtiofsd? > Are we going to support different version of qemu and virtiofsd > combination? I suppose we have to, as vhost-user protocol should allow > that, and it's nice to allow other to experiment and implement it in > different ways. > If not, then perhaps we should think about introducing some version > checking between qemu and external processes (with config_stamp, > similar to modules). It should support mismatched versions. We do have at least two extensions over the base we're working on (DAX and notification for blocking locks); I'd expect the sets of these to be posted close together but not be required to go in at the same time. > From what I understand, I think c) would be fine. However, for > convenience/testing reasons, b) would be my preference. Dave > -- > Marc-André Lureau > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
