On Dienstag, 23. April 2019 13:44:42 CEST Greg Kurz wrote:
> Hi Christian,
>
> Sorry for the late response. I'm quite busy on other topics these days...
Absolutely no problem. We probably all share the same fate of constant work
load on endless battle fields popping up everywhere. :-)
> > I int
Hi Christian,
Sorry for the late response. I'm quite busy on other topics these days...
On Sun, 21 Apr 2019 00:41:01 +0200
Christian Schoenebeck wrote:
> On Samstag, 30. März 2019 21:01:28 CEST Christian Schoenebeck wrote:
> > On Samstag, 30. März 2019 17:47:51 CET Greg Kurz wrote:
> > > Mayb
On Samstag, 30. März 2019 21:01:28 CEST Christian Schoenebeck wrote:
> On Samstag, 30. März 2019 17:47:51 CET Greg Kurz wrote:
> > Maybe have a look at this tentative to fix QID collisions:
> >
> > https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg02283.html
[snip]
> Question: so far I just
On Samstag, 30. März 2019 17:47:51 CET Greg Kurz wrote:
> Maybe have a look at this tentative to fix QID collisions:
>
> https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg02283.html
Interesting! My idea would have been different, based on my presumption that
the amount of devices on a 9p
On Sat, 30 Mar 2019 14:48:02 +0100
Christian Schoenebeck via Qemu-devel wrote:
> Hi list,
>
> currently the 9p implementation in qemu causes inode number collisions on
> guest OS level if the directory exported by 9p consists on host level of more
> than one file system being mounted inside th
Hi list,
currently the 9p implementation in qemu causes inode number collisions on
guest OS level if the directory exported by 9p consists on host level of more
than one file system being mounted inside that exported directory tree; which
leads to severe misbehaviours on guest side with all kin
