Re: virtiofsd: Where should it live?
We seem to be settling out to either fsdev/virtiofsd or tools/virtiofsd with tools picking up some speed as people seem to want to put a bunch of other stuff in there. Unless anyone shouts really loud, I'll work on making it tools/virtiofsd. Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: virtiofsd: Where should it live?
On 12/4/19 7:28 AM, Kevin Wolf wrote: Am 04.12.2019 um 09:17 hat Gerd Hoffmann geschrieben: Hi, | ... +- qemu-edid Has its own MAINTAINERS section, together with hw/display/edit* and include/hw/display/edid.h. I'm not sure moving it hw/display/ is a good idea. Gerd? Sort-of makes sense. My personal preference would be a tools/ directory for all those small utilities though. I think I would like that better than throwing tools into block/ where currently mostly just block drivers live. Ooh, I should have read this sub-thread before writing my reply at the top level. Yes, I like the idea of tools/ for qemu-img, qemu-io, and qemu-nbd better than block/. Or, if we want to move the tools there, we'd need another directory level inside block/ to keep things reasonably organised. Separating drivers from executables sounds worthwhile either way, whether that division is by a new tools/ or by a subdirectory in block/. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Re: virtiofsd: Where should it live?
On 12/4/19 1:43 AM, Markus Armbruster wrote: +- qemu-img | +- qemu-img.c Perhaps this one can all go into existing block/, similar to how pr-manager-helper.c is in scsi/, and virtfs-proxy-helper.c is in fsdev/. Up to the block maintainers, of course. +- qemu-nbd | +- qemu-nbd.c block/ or nbd/? I'd lean towards nbd/, but am open to opinions from other block maintainers. Kevin's plan to add a generic block utility that includes the functionality of qemu-nbd may also matter (where block/ starts to sound better). +- qemu-io | +- qemu-io.c | +- qemu-io-cmds.c block/? qemu-img and qemu-io in block/ sound reasonable to me. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Re: virtiofsd: Where should it live?
On 04/12/2019 14.28, Kevin Wolf wrote: > Am 04.12.2019 um 09:17 hat Gerd Hoffmann geschrieben: >> Hi, >> | ... +- qemu-edid >>> >>> Has its own MAINTAINERS section, together with hw/display/edit* and >>> include/hw/display/edid.h. I'm not sure moving it hw/display/ is a good >>> idea. Gerd? >> >> Sort-of makes sense. My personal preference would be a tools/ directory >> for all those small utilities though. > > I think I would like that better than throwing tools into block/ where > currently mostly just block drivers live. +1 for tools/ Thomas
Re: virtiofsd: Where should it live?
Am 04.12.2019 um 09:17 hat Gerd Hoffmann geschrieben: > Hi, > > > > | ... > > > +- qemu-edid > > > > Has its own MAINTAINERS section, together with hw/display/edit* and > > include/hw/display/edid.h. I'm not sure moving it hw/display/ is a good > > idea. Gerd? > > Sort-of makes sense. My personal preference would be a tools/ directory > for all those small utilities though. I think I would like that better than throwing tools into block/ where currently mostly just block drivers live. Or, if we want to move the tools there, we'd need another directory level inside block/ to keep things reasonably organised. Kevin
Re: virtiofsd: Where should it live?
"Dr. David Alan Gilbert" writes: > So what do you think of Paolo's suggestion of putting virtiofsd in > fsdev (mkdir fsdev/9p && mv fsdev/* fsdev/9p && mkdir fsdev/virtiofsd ) No objections. Flatter: fsdev-9p/ and fsdev-virtio/. Matter of taste.
Re: virtiofsd: Where should it live?
* Markus Armbruster (arm...@redhat.com) wrote: > Daniel P. Berrangé writes: > > > On Tue, Dec 03, 2019 at 11:06:44AM +, Peter Maydell wrote: > >> On Tue, 3 Dec 2019 at 10:53, Dr. David Alan Gilbert > >> wrote: > >> > > >> > We seem to be coming to the conclusion something that: > >> > > >> > a) It should live in the qemu tree > >> > b) It shouldn't live under contrib > >> > c) We'll create a new top level, i.e. 'daemons' > >> > d) virtiofsd will be daemons/virtiofsd > >> > > >> > Now, somethings I'm less clear on: > >> > e) What else would move into daemons? It was suggested > >> > that if we've got virtiofsd in there, then we should move > >> > libvhost-user - which I understand, but then it's not a > >> > 'daemons'. > >> > Are there any otehr daemons that should move? > >> > >> I like the idea of a new top level directory, but I think > >> 'daemons' is a bit too specific -- for instance it seems to > >> me that qemu-img would be sensible to move out of the root, > >> and that's not a daemon. > > > > Do we really need an extra directory level ? > > +1 > > > IIUC, the main point against having $GIT_ROOT/virtiofsd is that > > the root of our repo is quite cluttered already. > > > > Rather than trying to create a multi-level hierarchy which adds > > a debate around naming, why not address the clutter by moving > > *ALL* the .c/.h files out of the root so that we have a flatter > > tree: > > > > $GITROOT > > +- qemu-system > > | +- vl.c > > | +- ...most other files... > > Sounds good to me. > > > +- qemu-img > > | +- qemu-img.c > > Perhaps this one can all go into existing block/, similar to how > pr-manager-helper.c is in scsi/, and virtfs-proxy-helper.c is in fsdev/. > Up to the block maintainers, of course. > > > +- qemu-nbd > > | +- qemu-nbd.c > > block/ or nbd/? > > > +- qemu-io > > | +- qemu-io.c > > | +- qemu-io-cmds.c > > block/? > > > +- qemu-bridge-helper > > net/? > > > | ... > > +- qemu-edid > > Has its own MAINTAINERS section, together with hw/display/edit* and > include/hw/display/edid.h. I'm not sure moving it hw/display/ is a good > idea. Gerd? > > > +- qemu-keymap > > Not covered by MAINTAINERS. scripts/get_maintainer.pl --git-blame > points to Gerd. > > > +- qga (already exists) > > Yes. > > > Then we can add virtiofsd and other programs at the root with no big > > issue. > > We don't *have* to put each program into its own directory. Simple ones > could also share one. We just need a directory name. So what do you think of Paolo's suggestion of putting virtiofsd in fsdev (mkdir fsdev/9p && mv fsdev/* fsdev/9p && mkdir fsdev/virtiofsd ) Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: virtiofsd: Where should it live?
Hi, > > | ... > > +- qemu-edid > > Has its own MAINTAINERS section, together with hw/display/edit* and > include/hw/display/edid.h. I'm not sure moving it hw/display/ is a good > idea. Gerd? Sort-of makes sense. My personal preference would be a tools/ directory for all those small utilities though. > > +- qemu-keymap > > Not covered by MAINTAINERS. scripts/get_maintainer.pl --git-blame > points to Gerd. Generates the keymaps in pc-bios/keymaps/ cheers, Gerd
Re: virtiofsd: Where should it live?
Daniel P. Berrangé writes: > On Tue, Dec 03, 2019 at 11:06:44AM +, Peter Maydell wrote: >> On Tue, 3 Dec 2019 at 10:53, Dr. David Alan Gilbert >> wrote: >> > >> > We seem to be coming to the conclusion something that: >> > >> > a) It should live in the qemu tree >> > b) It shouldn't live under contrib >> > c) We'll create a new top level, i.e. 'daemons' >> > d) virtiofsd will be daemons/virtiofsd >> > >> > Now, somethings I'm less clear on: >> > e) What else would move into daemons? It was suggested >> > that if we've got virtiofsd in there, then we should move >> > libvhost-user - which I understand, but then it's not a >> > 'daemons'. >> > Are there any otehr daemons that should move? >> >> I like the idea of a new top level directory, but I think >> 'daemons' is a bit too specific -- for instance it seems to >> me that qemu-img would be sensible to move out of the root, >> and that's not a daemon. > > Do we really need an extra directory level ? +1 > IIUC, the main point against having $GIT_ROOT/virtiofsd is that > the root of our repo is quite cluttered already. > > Rather than trying to create a multi-level hierarchy which adds > a debate around naming, why not address the clutter by moving > *ALL* the .c/.h files out of the root so that we have a flatter > tree: > > $GITROOT > +- qemu-system > | +- vl.c > | +- ...most other files... Sounds good to me. > +- qemu-img > | +- qemu-img.c Perhaps this one can all go into existing block/, similar to how pr-manager-helper.c is in scsi/, and virtfs-proxy-helper.c is in fsdev/. Up to the block maintainers, of course. > +- qemu-nbd > | +- qemu-nbd.c block/ or nbd/? > +- qemu-io > | +- qemu-io.c > | +- qemu-io-cmds.c block/? > +- qemu-bridge-helper net/? > | ... > +- qemu-edid Has its own MAINTAINERS section, together with hw/display/edit* and include/hw/display/edid.h. I'm not sure moving it hw/display/ is a good idea. Gerd? > +- qemu-keymap Not covered by MAINTAINERS. scripts/get_maintainer.pl --git-blame points to Gerd. > +- qga (already exists) Yes. > Then we can add virtiofsd and other programs at the root with no big > issue. We don't *have* to put each program into its own directory. Simple ones could also share one. We just need a directory name.
Re: virtiofsd: Where should it live?
On Tue, 3 Dec 2019 13:10:46 + "Dr. David Alan Gilbert" wrote: > * Paolo Bonzini (pbonz...@redhat.com) wrote: > > On 03/12/19 14:02, Dr. David Alan Gilbert wrote: > > >> It could be in fsdev/virtiofsd, > > > fsdev is currently all 9p stuff, so that would seem very confusing. > > > > Move it to fsdev/9p? > > Greg: Are you OK with us doing that, and then having fsdev/virtiofsd for > our side of things? > That's okay with me. > > >> but I agree with Daniel that at this > > >> point the QEMU build system introduces baggage that you may not want for > > >> virtiofsd. > > > > > > I've already got it wired up in contrib with qemu's build system > > > so that doesn't seem to be an issue. The question is purely a 'where'. > > > > Oh I agree it's not an insurmountable problem. For a new project I may > > not want to deal with the complicated rules.mak stuff; however, if > > virtiofsd doesn't have to do anything complicated then it's your choice. > > Fortunately we don't seem to have touched that. > > Dave > > > Paolo > > > -- > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK >
Re: virtiofsd: Where should it live?
* Daniel P. Berrangé (berra...@redhat.com) wrote: > On Tue, Dec 03, 2019 at 11:06:44AM +, Peter Maydell wrote: > > On Tue, 3 Dec 2019 at 10:53, Dr. David Alan Gilbert > > wrote: > > > > > > We seem to be coming to the conclusion something that: > > > > > > a) It should live in the qemu tree > > > b) It shouldn't live under contrib > > > c) We'll create a new top level, i.e. 'daemons' > > > d) virtiofsd will be daemons/virtiofsd > > > > > > Now, somethings I'm less clear on: > > > e) What else would move into daemons? It was suggested > > > that if we've got virtiofsd in there, then we should move > > > libvhost-user - which I understand, but then it's not a > > > 'daemons'. > > > Are there any otehr daemons that should move? > > > > I like the idea of a new top level directory, but I think > > 'daemons' is a bit too specific -- for instance it seems to > > me that qemu-img would be sensible to move out of the root, > > and that's not a daemon. > > Do we really need an extra directory level ? > > IIUC, the main point against having $GIT_ROOT/virtiofsd is that > the root of our repo is quite cluttered already. > > Rather than trying to create a multi-level hierarchy which adds > a debate around naming, why not address the clutter by moving > *ALL* the .c/.h files out of the root so that we have a flatter > tree: > > $GITROOT > +- qemu-system > | +- vl.c > | +- ...most other files... This seems like a good idea anyway (are all these files -system not user?) > +- qemu-img > | +- qemu-img.c > +- qemu-nbd > | +- qemu-nbd.c > +- qemu-io > | +- qemu-io.c > | +- qemu-io-cmds.c > +- qemu-bridge-helper > | ... > +- qemu-edid > +- qemu-keymap > +- qga (already exists) I'm not seeing how having ~ one directory per file is helping; the number of entries doesn't drop much. > Then we can add virtiofsd and other programs at the root with no big > issue. Dave > 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 :| -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: virtiofsd: Where should it live?
On 03/12/19 14:02, Dr. David Alan Gilbert wrote: >> It could be in fsdev/virtiofsd, > fsdev is currently all 9p stuff, so that would seem very confusing. Move it to fsdev/9p? >> but I agree with Daniel that at this >> point the QEMU build system introduces baggage that you may not want for >> virtiofsd. > > I've already got it wired up in contrib with qemu's build system > so that doesn't seem to be an issue. The question is purely a 'where'. Oh I agree it's not an insurmountable problem. For a new project I may not want to deal with the complicated rules.mak stuff; however, if virtiofsd doesn't have to do anything complicated then it's your choice. Paolo
Re: virtiofsd: Where should it live?
* Paolo Bonzini (pbonz...@redhat.com) wrote: > On 03/12/19 14:02, Dr. David Alan Gilbert wrote: > >> It could be in fsdev/virtiofsd, > > fsdev is currently all 9p stuff, so that would seem very confusing. > > Move it to fsdev/9p? Greg: Are you OK with us doing that, and then having fsdev/virtiofsd for our side of things? > >> but I agree with Daniel that at this > >> point the QEMU build system introduces baggage that you may not want for > >> virtiofsd. > > > > I've already got it wired up in contrib with qemu's build system > > so that doesn't seem to be an issue. The question is purely a 'where'. > > Oh I agree it's not an insurmountable problem. For a new project I may > not want to deal with the complicated rules.mak stuff; however, if > virtiofsd doesn't have to do anything complicated then it's your choice. Fortunately we don't seem to have touched that. Dave > Paolo > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: virtiofsd: Where should it live?
* Paolo Bonzini (pbonz...@redhat.com) wrote: > On 26/11/19 13:14, Dr. David Alan Gilbert wrote: > >> IOW, if we did decide we want it in QEMU, then instead of > >> '$GIT/contrib/virtiofsd', I'd prefer to see '$GIT/virtiofsd'. > > > > I'm not sure it deserves a new top level for such a specific tool. > > > > It could be in fsdev/virtiofsd, fsdev is currently all 9p stuff, so that would seem very confusing. > but I agree with Daniel that at this > point the QEMU build system introduces baggage that you may not want for > virtiofsd. I've already got it wired up in contrib with qemu's build system so that doesn't seem to be an issue. The question is purely a 'where'. Dave > Paolo > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: virtiofsd: Where should it live?
On 26/11/19 13:14, Dr. David Alan Gilbert wrote: >> IOW, if we did decide we want it in QEMU, then instead of >> '$GIT/contrib/virtiofsd', I'd prefer to see '$GIT/virtiofsd'. > > I'm not sure it deserves a new top level for such a specific tool. > It could be in fsdev/virtiofsd, but I agree with Daniel that at this point the QEMU build system introduces baggage that you may not want for virtiofsd. Paolo
Re: virtiofsd: Where should it live?
On Tue, Dec 03, 2019 at 11:06:44AM +, Peter Maydell wrote: > On Tue, 3 Dec 2019 at 10:53, Dr. David Alan Gilbert > wrote: > > > > We seem to be coming to the conclusion something that: > > > > a) It should live in the qemu tree > > b) It shouldn't live under contrib > > c) We'll create a new top level, i.e. 'daemons' > > d) virtiofsd will be daemons/virtiofsd > > > > Now, somethings I'm less clear on: > > e) What else would move into daemons? It was suggested > > that if we've got virtiofsd in there, then we should move > > libvhost-user - which I understand, but then it's not a > > 'daemons'. > > Are there any otehr daemons that should move? > > I like the idea of a new top level directory, but I think > 'daemons' is a bit too specific -- for instance it seems to > me that qemu-img would be sensible to move out of the root, > and that's not a daemon. Do we really need an extra directory level ? IIUC, the main point against having $GIT_ROOT/virtiofsd is that the root of our repo is quite cluttered already. Rather than trying to create a multi-level hierarchy which adds a debate around naming, why not address the clutter by moving *ALL* the .c/.h files out of the root so that we have a flatter tree: $GITROOT +- qemu-system | +- vl.c | +- ...most other files... +- qemu-img | +- qemu-img.c +- qemu-nbd | +- qemu-nbd.c +- qemu-io | +- qemu-io.c | +- qemu-io-cmds.c +- qemu-bridge-helper | ... +- qemu-edid +- qemu-keymap +- qga (already exists) Then we can add virtiofsd and other programs at the root with no big issue. 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 :|
Re: virtiofsd: Where should it live?
* Peter Maydell (peter.mayd...@linaro.org) wrote: > On Tue, 3 Dec 2019 at 10:53, Dr. David Alan Gilbert > wrote: > > > > We seem to be coming to the conclusion something that: > > > > a) It should live in the qemu tree > > b) It shouldn't live under contrib > > c) We'll create a new top level, i.e. 'daemons' > > d) virtiofsd will be daemons/virtiofsd > > > > Now, somethings I'm less clear on: > > e) What else would move into daemons? It was suggested > > that if we've got virtiofsd in there, then we should move > > libvhost-user - which I understand, but then it's not a > > 'daemons'. > > Are there any otehr daemons that should move? > > I like the idea of a new top level directory, but I think > 'daemons' is a bit too specific -- for instance it seems to > me that qemu-img would be sensible to move out of the root, > and that's not a daemon. What would your preference be? Thomas was suggesting 'tools'. Dave > thanks > -- PMM > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: virtiofsd: Where should it live?
On Tue, 3 Dec 2019 at 10:53, Dr. David Alan Gilbert wrote: > > We seem to be coming to the conclusion something that: > > a) It should live in the qemu tree > b) It shouldn't live under contrib > c) We'll create a new top level, i.e. 'daemons' > d) virtiofsd will be daemons/virtiofsd > > Now, somethings I'm less clear on: > e) What else would move into daemons? It was suggested > that if we've got virtiofsd in there, then we should move > libvhost-user - which I understand, but then it's not a > 'daemons'. > Are there any otehr daemons that should move? I like the idea of a new top level directory, but I think 'daemons' is a bit too specific -- for instance it seems to me that qemu-img would be sensible to move out of the root, and that's not a daemon. thanks -- PMM
Re: virtiofsd: Where should it live?
We seem to be coming to the conclusion something that: a) It should live in the qemu tree b) It shouldn't live under contrib c) We'll create a new top level, i.e. 'daemons' d) virtiofsd will be daemons/virtiofsd Now, somethings I'm less clear on: e) What else would move into daemons? It was suggested that if we've got virtiofsd in there, then we should move libvhost-user - which I understand, but then it's not a 'daemons'. Are there any otehr daemons that should move? f) Should virtiofsd always be built (if the deps are installed)? Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: virtiofsd: Where should it live?
Dr. David Alan Gilbert writes: > 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 In so far as there is much discussion of "multi-process qemu", I wonder if it would not be time to create a "processes" subdirectory, and have virtiofsd be the first entry there. Thomas Huth suggested "tools", but I tend to read "tools" as things that are used during the build process. > > Your suggestions/ideas please. My preference is (a). > > Dave -- Cheers, Christophe de Dinechin (IRC c3d)
Re: virtiofsd: Where should it live?
* Michael S. Tsirkin (m...@redhat.com) wrote: > On Mon, Dec 02, 2019 at 04:44:23PM +, Dr. David Alan Gilbert wrote: > > * Michael S. Tsirkin (m...@redhat.com) wrote: > > > On Mon, Nov 25, 2019 at 06:50:21PM +, 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 / dgilb...@redhat.com / Manchester, UK > > > > > > > > > -- > > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: virtiofsd: Where should it live?
On Mon, Dec 02, 2019 at 04:44:23PM +, Dr. David Alan Gilbert wrote: > * Michael S. Tsirkin (m...@redhat.com) wrote: > > On Mon, Nov 25, 2019 at 06:50:21PM +, 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. > > 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? > > > > > > > > -- > > > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK > > > > > > -- > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: virtiofsd: Where should it live?
* Michael S. Tsirkin (m...@redhat.com) wrote: > On Mon, Nov 25, 2019 at 06:50:21PM +, 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 / dgilb...@redhat.com / Manchester, UK > > > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: virtiofsd: Where should it live?
* Markus Armbruster (arm...@redhat.com) wrote: > Thomas Huth writes: > > > On 02/12/2019 13.56, Markus Armbruster wrote: > >> Peter Maydell writes: > >> > >>> On Tue, 26 Nov 2019 at 12:15, Dr. David Alan Gilbert > >>> wrote: > > * Daniel P. Berrangé (berra...@redhat.com) wrote: > > 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. > >>> > > 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'. > > I'm not sure it deserves a new top level for such a specific tool. > >>> > >>> Maybe, but I think I agree with Daniel that 'contrib/' is > >>> probably not the right place for it if it's something that > >>> we care about supporting. 'contrib' to me is "bucket of stuff > >>> that we didn't really feel strongly we wanted to reject but > >>> which is probably random special-cases or other obscure > >>> stuff, don't bother looking in here and don't assume it's > >>> going to work either". > >> > >> Agree. > >> > >> We have source for several separate programs in the root directory > >> already: qemu-bridge-helper, qemu-edid, qemu-img, qemu-io, qemu-nbd, > >> qemu-keymap, qemu-seccomp, qemu-ga. Just a .c file when that suffixes, > >> else a subdirectory, except for qemu-io, which is two .c files in the > >> root, plus include/qemu-io.h. Putting virtiofsd/ there follows > >> qemu-ga's precedence. > > > > IMHO the root directory is still way too overcrowded. Maybe we should > > simply introduce a "tools" subdirectory? > > Maybe. In general, I prefer my source trees shallow. I think I agree with Thomas that it should be in a subdirectory for all tools like that; creating virtiofsd at the top level feels wrong to me since it's just too specific. Someone please pick a name :-) > We've sucked at keeping new files out of the root that don't belong > there. Mending our ways going forward is just one half of the fix. The > other half is cleaning up the mess we made. It's been getting better over time mostly. We could lose qemu-bridge-helper.c into this new directory. Dave > The manual should be somewhere below docs/. > > Several .[ch] should be in a suitable subdirectory. > > $ git-ls-files | grep -v / | grep '\.[ch]$' > arch_init.c > balloon.c > block.c > blockdev-nbd.c > blockdev.c > blockjob.c > bootdevice.c > bt-host.c > bt-vhci.c > cpus-common.c > cpus.c > device-hotplug.c > device_tree.c > disas.c > dma-helpers.c > exec-vary.c > exec.c > gdbstub.c > ioport.c > iothread.c > job-qmp.c > job.c > memory.c > memory_ldst.inc.c > memory_mapping.c > module-common.c > os-posix.c > os-win32.c > qdev-monitor.c > qemu-bridge-helper.c > qemu-edid.c > qemu-img.c > qemu-io-cmds.c > qemu-io.c > qemu-keymap.c > qemu-nbd.c > qemu-options-wrapper.h > qemu-options.h > qemu-seccomp.c > qtest.c > replication.c > replication.h > thunk.c > tpm.c > vl.c -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: virtiofsd: Where should it live?
Thomas Huth writes: > On 02/12/2019 13.56, Markus Armbruster wrote: >> Peter Maydell writes: >> >>> On Tue, 26 Nov 2019 at 12:15, Dr. David Alan Gilbert >>> wrote: * Daniel P. Berrangé (berra...@redhat.com) wrote: > 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. >>> > 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'. I'm not sure it deserves a new top level for such a specific tool. >>> >>> Maybe, but I think I agree with Daniel that 'contrib/' is >>> probably not the right place for it if it's something that >>> we care about supporting. 'contrib' to me is "bucket of stuff >>> that we didn't really feel strongly we wanted to reject but >>> which is probably random special-cases or other obscure >>> stuff, don't bother looking in here and don't assume it's >>> going to work either". >> >> Agree. >> >> We have source for several separate programs in the root directory >> already: qemu-bridge-helper, qemu-edid, qemu-img, qemu-io, qemu-nbd, >> qemu-keymap, qemu-seccomp, qemu-ga. Just a .c file when that suffixes, >> else a subdirectory, except for qemu-io, which is two .c files in the >> root, plus include/qemu-io.h. Putting virtiofsd/ there follows >> qemu-ga's precedence. > > IMHO the root directory is still way too overcrowded. Maybe we should > simply introduce a "tools" subdirectory? Maybe. In general, I prefer my source trees shallow. We've sucked at keeping new files out of the root that don't belong there. Mending our ways going forward is just one half of the fix. The other half is cleaning up the mess we made. The manual should be somewhere below docs/. Several .[ch] should be in a suitable subdirectory. $ git-ls-files | grep -v / | grep '\.[ch]$' arch_init.c balloon.c block.c blockdev-nbd.c blockdev.c blockjob.c bootdevice.c bt-host.c bt-vhci.c cpus-common.c cpus.c device-hotplug.c device_tree.c disas.c dma-helpers.c exec-vary.c exec.c gdbstub.c ioport.c iothread.c job-qmp.c job.c memory.c memory_ldst.inc.c memory_mapping.c module-common.c os-posix.c os-win32.c qdev-monitor.c qemu-bridge-helper.c qemu-edid.c qemu-img.c qemu-io-cmds.c qemu-io.c qemu-keymap.c qemu-nbd.c qemu-options-wrapper.h qemu-options.h qemu-seccomp.c qtest.c replication.c replication.h thunk.c tpm.c vl.c
Re: virtiofsd: Where should it live?
On 02/12/2019 13.56, Markus Armbruster wrote: > Peter Maydell writes: > >> On Tue, 26 Nov 2019 at 12:15, Dr. David Alan Gilbert >> wrote: >>> >>> * Daniel P. Berrangé (berra...@redhat.com) wrote: 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. >> 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'. >>> >>> I'm not sure it deserves a new top level for such a specific tool. >> >> Maybe, but I think I agree with Daniel that 'contrib/' is >> probably not the right place for it if it's something that >> we care about supporting. 'contrib' to me is "bucket of stuff >> that we didn't really feel strongly we wanted to reject but >> which is probably random special-cases or other obscure >> stuff, don't bother looking in here and don't assume it's >> going to work either". > > Agree. > > We have source for several separate programs in the root directory > already: qemu-bridge-helper, qemu-edid, qemu-img, qemu-io, qemu-nbd, > qemu-keymap, qemu-seccomp, qemu-ga. Just a .c file when that suffixes, > else a subdirectory, except for qemu-io, which is two .c files in the > root, plus include/qemu-io.h. Putting virtiofsd/ there follows > qemu-ga's precedence. IMHO the root directory is still way too overcrowded. Maybe we should simply introduce a "tools" subdirectory? Thomas
Re: virtiofsd: Where should it live?
Peter Maydell writes: > On Tue, 26 Nov 2019 at 12:15, Dr. David Alan Gilbert > wrote: >> >> * Daniel P. Berrangé (berra...@redhat.com) wrote: >> > 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. > >> > 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'. >> >> I'm not sure it deserves a new top level for such a specific tool. > > Maybe, but I think I agree with Daniel that 'contrib/' is > probably not the right place for it if it's something that > we care about supporting. 'contrib' to me is "bucket of stuff > that we didn't really feel strongly we wanted to reject but > which is probably random special-cases or other obscure > stuff, don't bother looking in here and don't assume it's > going to work either". Agree. We have source for several separate programs in the root directory already: qemu-bridge-helper, qemu-edid, qemu-img, qemu-io, qemu-nbd, qemu-keymap, qemu-seccomp, qemu-ga. Just a .c file when that suffixes, else a subdirectory, except for qemu-io, which is two .c files in the root, plus include/qemu-io.h. Putting virtiofsd/ there follows qemu-ga's precedence. There's also precedence for putting such programs into their subsystem's sub-directory: fsdev/virtfs-proxy-helper, scsi/pr-manager-helper.
Re: virtiofsd: Where should it live?
On Tue, 26 Nov 2019 at 12:15, Dr. David Alan Gilbert wrote: > > * Daniel P. Berrangé (berra...@redhat.com) wrote: > > 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. > > 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'. > > I'm not sure it deserves a new top level for such a specific tool. Maybe, but I think I agree with Daniel that 'contrib/' is probably not the right place for it if it's something that we care about supporting. 'contrib' to me is "bucket of stuff that we didn't really feel strongly we wanted to reject but which is probably random special-cases or other obscure stuff, don't bother looking in here and don't assume it's going to work either". thanks -- PMM
Re: virtiofsd: Where should it live?
On Mon, Nov 25, 2019 at 06:50:21PM +, 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. 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"? > > -- > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK >
Re: virtiofsd: Where should it live?
* Daniel P. Berrangé (berra...@redhat.com) wrote: > On Mon, Nov 25, 2019 at 06:50:21PM +, 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'. I'm not sure it deserves a new top level for such a specific tool. > > 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. Form virtiofsd's point of view I'm not that worried about the release cycle; Given that features have to go through virtio standardisation, the release ycle is unlikely to be a bottleneck. > 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. As a qemu contributor, your opinion is welcome! No need to sit on the fence. > 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. > Dave > 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 :| -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: virtiofsd: Where should it live?
* Marc-André Lureau (marcandre.lur...@gmail.com) wrote: > Hi David > > On Mon, Nov 25, 2019 at 10:50 PM 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 > > > > 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
Re: virtiofsd: Where should it live?
On Mon, Nov 25, 2019 at 06:50:21PM +, 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 :|
Re: virtiofsd: Where should it live?
Hi David On Mon, Nov 25, 2019 at 10:50 PM 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 > > 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. 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). >From what I understand, I think c) would be fine. However, for convenience/testing reasons, b) would be my preference. -- Marc-André Lureau
virtiofsd: Where should it live?
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). Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
