Re: [Qemu-devel] [libvirt patch] qemu: adds support for virtfs 9p argument 'vii'

[Greg Kurz]

On Tue, 07 May 2019 14:23:11 +0200
Christian Schoenebeck <address@hidden> 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 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
> 

For a reason yet to be investigated, I haven't received it yet...

> 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:
> 

I'll try but probably not before next week.

> 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 address@hidden 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