On Montag, 3. Juni 2019 08:57:15 CEST Greg Kurz wrote:
> > Ok, I will extend Antonios' patch to log that error on host. I thought
> > about limiting that error message to once per session (for not flooding
> > the logs), but it is probably not worth it, so if you don't veto then I
> > will just log
On Wed, 22 May 2019 18:03:13 +0200
Christian Schoenebeck wrote:
> On Montag, 20. Mai 2019 16:05:09 CEST Greg Kurz wrote:
> > Hi Christian,
>
> Hi Greg,
>
> > On the other hand, I'm afraid that having a functional solution won't
> > motivate people to come up with a new spec... Anyway, I agree
On Montag, 20. Mai 2019 16:05:09 CEST Greg Kurz wrote:
> Hi Christian,
Hi Greg,
> On the other hand, I'm afraid that having a functional solution won't
> motivate people to come up with a new spec... Anyway, I agree that the
> data corruption/loss issues must be prevented, ie, the 9p server shoul
Hi Christian,
On Fri, 17 May 2019 22:53:41 +0200
Christian Schoenebeck wrote:
> On Freitag, 17. Mai 2019 16:47:46 CEST Greg Kurz wrote:
> > Potentially yes if another approach is satisfying enough, as I wouldn't
> > want to over-engineer too much around this 9p imposed limitation. The
> > right
On Freitag, 17. Mai 2019 16:47:46 CEST Greg Kurz wrote:
> Potentially yes if another approach is satisfying enough, as I wouldn't
> want to over-engineer too much around this 9p imposed limitation. The
> right thing to do would be to come up with a new version of the protocol
> with variable sized
On Fri, 17 May 2019 15:23:01 +0200
Christian Schoenebeck wrote:
> On Freitag, 17. Mai 2019 14:30:29 CEST Greg Kurz wrote:
> > Then, we come to the bulk problem: how to handle the case where we
> > have multiple devices involved in a directory we want to share ?
> > Antonios's proposal is a clever
On Freitag, 17. Mai 2019 14:30:29 CEST Greg Kurz wrote:
> Then, we come to the bulk problem: how to handle the case where we
> have multiple devices involved in a directory we want to share ?
> Antonios's proposal is a clever way to address the collisions, but
> your work proves it isn't enough...
On Fri, 17 May 2019 10:40:48 +0200
Christian Schoenebeck wrote:
> On Dienstag, 7. Mai 2019 18:16:08 CEST Christian Schoenebeck wrote:
> > Here are the archive links for latest v3 patch set [5(+1) patches total]:
> >
> > [PATCH v3 0/5] 9p: Fix file ID collisions:
> > https://lists.gnu.org/archive
On Dienstag, 7. Mai 2019 18:16:08 CEST Christian Schoenebeck wrote:
> Here are the archive links for latest v3 patch set [5(+1) patches total]:
>
> [PATCH v3 0/5] 9p: Fix file ID collisions:
> https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01143.html
>
> [PATCH v3 1/5] 9p: mitigates mos
On Dienstag, 7. Mai 2019 17:42:39 CEST Greg Kurz wrote:
> > Sorry that I caused a bit of confusion, You were actually commenting
> > mostly on v2 of the patch set, where my email client replaced the message
> > IDs and hence screwed threading.
> >
> > This is v3 that I sent yesterday and which has
On Tue, 07 May 2019 14:23:11 +0200
Christian Schoenebeck wrote:
> On Dienstag, 7. Mai 2019 11:55:56 CEST Greg Kurz wrote:
> > > support the 'vii' feature of patch 5, which introduces the XML config
> >
> > What is patch 5 ?!? What is 'vii' ? I am a bit lost here...
>
> Hi Greg,
>
> Sorry t
On Dienstag, 7. Mai 2019 13:57:56 CEST Daniel P. Berrangé wrote:
> > ...
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Like with the vii qemu virtfs command line argument, the order of the
> > "importan
On Mon, May 06, 2019 at 07:58:28PM +0200, Christian Schoenebeck via Qemu-devel
wrote:
> This is the counter part patch against latest libvirt git master head to
> support the 'vii' feature of patch 5, which introduces the XML config
> XML tag "important" on libvirt side.
>
> To stick with the pre
On Dienstag, 7. Mai 2019 11:55:56 CEST Greg Kurz wrote:
> > support the 'vii' feature of patch 5, which introduces the XML config
>
> What is patch 5 ?!? What is 'vii' ? I am a bit lost here...
Hi Greg,
Sorry that I caused a bit of confusion, You were actually commenting mostly on
v2 of the pat
On Mon, 06 May 2019 19:58:28 +0200
Christian Schoenebeck wrote:
> This is the counter part patch against latest libvirt git master head to
Hmm... shouldn't this be Cc'd to libvir-l...@redhat.com as well then ?
> support the 'vii' feature of patch 5, which introduces the XML config
What is patc
This is the counter part patch against latest libvirt git master head to
support the 'vii' feature of patch 5, which introduces the XML config
XML tag "important" on libvirt side.
To stick with the previous example mentioned with patch 5, likewise
libvirt XML configuration might then look like thi
16 matches
Mail list logo
