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 /
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-o
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
| +-
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
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 sen
"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.
* 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:
> >> >
> >>
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 smal
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 liv
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 t
* 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
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
>> vir
* 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/virtiofs
* 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
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
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
* 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 lev
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
>
> N
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? I
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 livh
* 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 d
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
* 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
* 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:
> >>>
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 notion
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 d
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 ei
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 p
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.
>
>
* 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, bec
* 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
> > thi
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.
>
>
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.
>
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 li
34 matches
Mail list logo
