qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: virtiofsd: Where should it live?


From: Dr. David Alan Gilbert
Subject: Re: virtiofsd: Where should it live?
Date: Mon, 2 Dec 2019 16:44:23 +0000
User-agent: Mutt/1.12.1 (2019-06-15)

* 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.

> 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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]