[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: |
Tue, 26 Nov 2019 11:42:53 +0000 |
User-agent: |
Mutt/1.12.1 (2019-06-15) |
* Marc-André Lureau (address@hidden) wrote:
> Hi David
>
> On Mon, Nov 25, 2019 at 10:50 PM Dr. David Alan Gilbert
> <address@hidden> 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 / address@hidden / Manchester, UK