From: Greg Kurz <groug@kaod.org>
To: Christian Schoenebeck <qemu_oss@crudebyte.com>
Cc: "Stefan Hajnoczi" <stefanha@gmail.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
qemu-devel@nongnu.org,
"Antonios Motakis" <antonios.motakis@huawei.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v7 0/3] 9p: Fix file ID collisions
Date: Mon, 23 Sep 2019 14:56:11 +0200 [thread overview]
Message-ID: <20190923145611.7ca240e8@bahia.lan> (raw)
In-Reply-To: <2376196.qMJLftDnS9@silver>
On Mon, 23 Sep 2019 11:50:46 +0200
Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> On Freitag, 13. September 2019 19:01:57 CEST Greg Kurz wrote:
> > So I did some changes in 1/3 and pushed everything to 9p-next.
>
> I've reviewed your changes. Some notes:
>
> Patch 1:
> https://github.com/gkurz/qemu/commit/9295011c5a961603959b966c8aa6ad9840fe6db2
>
> * Typo 1:
>
> error_append_hint(&local_err, "Valide options are: multidevs="
>
> Valide -> Valid
>
> * Typo 2 in log comment:
>
> [groug: - Moved "multidevs" parsing the local backend.
> ->
> [groug: - Moved "multidevs" parsing to the local backend.
>
Fixed.
> > I'll do some
> > more manual testing and issue a PR when I'm confident enough.
>
> That would be highly appreciated! So far I am the only one ever having tested
> this patch set at all!
>
Just to clarify, I won't thoroughly test it. My main concern is that it
doesn't break things. I usually rely on this:
https://www.tuxera.com/community/posix-test-suite/
> > It would be nice to have some sort of automated test for that in 'make
> > check'. My first thought is to simulate a cross-device setup with the synth
> > backend, because it might be difficult to do this on a real filesystem
> > without requiring elevated privileges.
>
> Hmm, since I neither haven't used the synth backend before, nor added qemu
> test cases so far, I am yet missing the complete picture here. My initial
> suggested approach would have been using loopback devices for simulating two
> file systems, but yes that's probably not viable due to required permissions.
> How would the synth backend help here? I mean you would need to simulate
> specific inode numbers and device numbers in some way for the test cases.
>
The synth backend allows to simulate anything you want, provided you
code it of course :)
It is currently used to run some 9p protocol conformance tests. Have a
look at the backend code to get the idea.
hw/9pfs/9p-synth.h
hw/9pfs/9p-synth.c
and the test program:
tests/virtio-9p-test.c
It currently doesn't care for st_dev/st_ino at all, but I guess
it shouldn't be that hard to add the necessary bits.
>
>
next prev parent reply other threads:[~2019-09-23 12:57 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-05 10:42 [Qemu-devel] [PATCH v7 0/3] 9p: Fix file ID collisions Christian Schoenebeck via Qemu-devel
2019-09-04 21:34 ` [Qemu-devel] [PATCH v7 1/3] 9p: Added virtfs option 'multidevs=remap|forbid|warn' Christian Schoenebeck via Qemu-devel
2019-09-04 22:05 ` [Qemu-devel] [PATCH v7 2/3] 9p: stat_to_qid: implement slow path Christian Schoenebeck via Qemu-devel
2019-09-04 22:53 ` [Qemu-devel] [PATCH v7 3/3] 9p: Use variable length suffixes for inode remapping Christian Schoenebeck via Qemu-devel
2019-09-13 17:01 ` [Qemu-devel] [PATCH v7 0/3] 9p: Fix file ID collisions Greg Kurz
2019-09-23 9:50 ` Christian Schoenebeck via
2019-09-23 12:56 ` Greg Kurz [this message]
2019-09-23 14:06 ` Christian Schoenebeck via
2019-09-23 14:46 ` Greg Kurz
2019-09-23 15:03 ` Christian Schoenebeck via
2019-09-23 16:50 ` Greg Kurz
2019-09-24 9:31 ` Christian Schoenebeck via
2019-10-08 9:14 ` Greg Kurz
2019-10-08 12:05 ` Christian Schoenebeck
2019-10-08 13:47 ` Greg Kurz
2019-10-08 14:25 ` Christian Schoenebeck
2019-10-08 14:45 ` Greg Kurz
2019-10-15 9:20 ` Greg Kurz
2019-10-16 9:42 ` virtio-fs: Fix file ID collisions (was: 9p: Fix file ID collisions) Christian Schoenebeck
2019-10-16 13:44 ` Dr. David Alan Gilbert
2019-10-18 13:15 ` Christian Schoenebeck
2019-10-16 14:00 ` Greg Kurz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190923145611.7ca240e8@bahia.lan \
--to=groug@kaod.org \
--cc=antonios.motakis@huawei.com \
--cc=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu_oss@crudebyte.com \
--cc=stefanha@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.