Re: virtiofsd: Where should it live?

[Dr. David Alan Gilbert]

* Michael S. Tsirkin (address@hidden) wrote:
> On Mon, Dec 02, 2019 at 04:44:23PM +0000, Dr. David Alan Gilbert wrote:
> > * Michael S. Tsirkin (address@hidden) wrote:
> > > 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.
> > > 
> > > Generally there could be some ifdefs that allow one to
> > > build libfuse-host or whatever from the same source.
> > > I am guessing the big reason this doesn't fly is that
> > > libfuse is not actively developed anymore.
> > 
> > libfuse is certainly taking patches; so it's not dead.
> > However, the changes for the transport are quite invasive,
> > and it doesn't feel right to impose them on it.
> > We've pushed up small fixes/changes etc - but not things
> > that are big intrusive lumps for our use.
> 
> Maybe they will want these patches then ....  The big question would be
> around security, e.g.  what if you rebase, how do you know they didn't
> introduce what is a security hole for virtiofsd ...  But then, that
> question remains even if you keep a separate tree.

It's active but slow moving; ~10 patches/month - so not too bad to
inspect.

> > > Given that, the main remaining part is libvhost-user,
> > > and it's less work to use than to duplicate that.
> > > That kind of dictates being in qemu.
> > > 
> > > >  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).
> > > > 
> > > > Dave
> > > 
> > > 
> > > My preference is close to a, and maybe to avoid confusion we should have
> > > a new top-level directory for "separate daemons qemu invokes, and need
> > > to be built together with qemu". libvhost-user would have to move there,
> > > too. "modules"?
> > 
> > "modules" feels too close to "plugins" to my mind.
> > 
> > Dave
> 
> daemons?

I'm OK with that.

Dave

> > > 
> > > > 
> > > > --
> > > > Dr. David Alan Gilbert / address@hidden / Manchester, UK
> > > > 
> > > 
> > --
> > Dr. David Alan Gilbert / address@hidden / Manchester, UK
> 
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK