qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Christian Schoenebeck via Qemu-devel <qemu-devel@nongnu.org>
To: qemu-devel@nongnu.org
Cc: Greg Kurz <groug@kaod.org>,
	Antonios Motakis <antonios.motakis@huawei.com>
Subject: Re: [Qemu-devel] [libvirt patch] qemu: adds support for virtfs 9p argument 'vii'
Date: Tue, 07 May 2019 14:23:11 +0200	[thread overview]
Message-ID: <3336211.WybC1Bzqah@silver> (raw)
In-Reply-To: <20190507115556.3d578690@bahia.lan>

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 patch set, where my email client replaced the message IDs and hence 
screwed threading.

This is v3 that I sent yesterday and which has correct threading:
https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01143.html

Please just have a glimpse on that v3 thread, and before I address the details 
that you requested (I have reviewed them all already and will address them), I 
would like you to ask you for a coarse feedback on design/features first. 
Because there are some things where I am unresolved on design level yet:

1. Should I drop the "persistency" feature of patch 3 (same inode numbers 
after reboots/suspends)  completely from the patch set? It is disabled at 
compile time by default for now after entire v3 patch set is applied. Or 
should that persistency feature probably become a qemu command line option 
instead?

2. If persistency feature should be preserved, shall I probably move out all 
the inode remapping code into a separate C unit to avoid 9p.c getting bloated 
too much (the amount of code for saving/loading the qp*_table hash tables is 
quite large). If yes, any suggestion for an appropriate unit name?

3. Are you fine with the suggested variable length suffixes (patch 4) becoming 
the default behaviour (instead of the fixed length 16 bit prefix solution by 
Antonios)?

4. Do you have a better idea for a name instead of the suggested "vii" (patch 
5) virtfs qemu command line option? And are you fine with the idea of that 
"vii" feature anyway?

> > This is the counter part patch against latest libvirt git master head to
> 
> Hmm... shouldn't this be Cc'd to libvir-list@redhat.com as well then ?

Well, for now I just provided that libvirt patch to give you an idea about how 
imagined this "vii" feature to be used. Does it make sense to CC them already 
even though this suggested "vii" command line option does not exist on qemu 
side yet?

I know I piled up quite a bit of code on this patch set, so to speed up things 
simply raise questions instead of spending too much time in reviewing 
everything in detail already.

Thanks Greg!

Best regards,
Christian Schoenebeck


  reply	other threads:[~2019-05-07 12:24 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-06 14:37 [Qemu-devel] [PATCH v3 0/5] 9p: Fix file ID collisions Christian Schoenebeck via Qemu-devel
2019-04-23 11:30 ` [Qemu-devel] [PATCH v3 1/5] 9p: mitigates most QID path collisions Christian Schoenebeck via Qemu-devel
2019-05-07 12:42   ` Daniel P. Berrangé
2019-05-07 13:11     ` Christian Schoenebeck via Qemu-devel
2019-05-07 13:13       ` Daniel P. Berrangé
2019-04-23 11:35 ` [Qemu-devel] [PATCH v3 2/5] 9P: trivial cleanup of QID path collision mitigation Christian Schoenebeck via Qemu-devel
2019-05-07 12:43   ` Daniel P. Berrangé
2019-04-23 11:41 ` [Qemu-devel] [PATCH v3 3/5] 9p: persistency of QID path beyond reboots / suspensions Christian Schoenebeck via Qemu-devel
2019-05-03 14:51 ` [Qemu-devel] [PATCH v3 4/5] 9p: use variable length suffixes for inode mapping Christian Schoenebeck via Qemu-devel
2019-05-05 21:41 ` [Qemu-devel] [PATCH v3 5/5] 9p: adds virtfs 'vii' device parameter Christian Schoenebeck via Qemu-devel
2019-05-06 17:58   ` [Qemu-devel] [libvirt patch] qemu: adds support for virtfs 9p argument 'vii' Christian Schoenebeck via Qemu-devel
2019-05-07  9:55     ` Greg Kurz
2019-05-07 12:23       ` Christian Schoenebeck via Qemu-devel [this message]
2019-05-07 15:42         ` Greg Kurz
2019-05-07 16:16           ` Christian Schoenebeck via Qemu-devel
2019-05-17  8:40             ` Christian Schoenebeck via Qemu-devel
2019-05-17 12:30               ` Greg Kurz
2019-05-17 13:23                 ` Christian Schoenebeck via Qemu-devel
2019-05-17 14:47                   ` Greg Kurz
2019-05-17 20:53                     ` Christian Schoenebeck via Qemu-devel
2019-05-20 14:05                       ` Greg Kurz
2019-05-22 16:03                         ` Christian Schoenebeck via Qemu-devel
2019-06-03  6:57                           ` Greg Kurz
2019-06-03  9:17                             ` Christian Schoenebeck via Qemu-devel
2019-05-07 12:57     ` Daniel P. Berrangé
2019-05-07 13:48       ` Christian Schoenebeck via Qemu-devel

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=3336211.WybC1Bzqah@silver \
    --to=qemu-devel@nongnu.org \
    --cc=antonios.motakis@huawei.com \
    --cc=groug@kaod.org \
    --cc=qemu_oss@crudebyte.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).