qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/2 v16] fsdev: add IO throttle support to fsdev


From: Greg Kurz
Subject: Re: [Qemu-devel] [PATCH 1/2 v16] fsdev: add IO throttle support to fsdev devices
Date: Tue, 7 Feb 2017 17:29:33 +0100

Cc'ing Stefan who reviewed patch 2/2.

On Tue, 7 Feb 2017 09:56:08 -0600
Eric Blake <address@hidden> wrote:

> On 02/07/2017 04:32 AM, Greg Kurz wrote:
> >>
> >> I'm not aware of anything related to fsdev in QMP... and libvirt seems to
> >> only parse the output of -help to guess fsdev capabilities.  
> > 
> > Oops, reading some more libvirt code I now see that libvirt doesn't parse
> > -help anymore with QEMU >= 1.2.0... sorry for the noise :)
> >   
> >> And indeed,
> >> qemu-options.hx doesn't expose this new feature.
> >>  
> >>> Please make sure we don't reach 2.9 with only a half-baked feature;
> >>> whether that means finishing the QMP work or temporarily disabling the
> >>> cli additions until a later release can finish the work.
> >>>     
> >>
> >> Would this be ok to add the missing bits in qemu-options.hx or do you
> >> expect more ?  
> 
> If it cannot be probed via QMP, then libvirt will most likely assume
> that it does not exist.  I guess we're okay having command line only in
> 2.9 if you can't get QMP working, because libvirt will just never drive
> the feature until 2.10 when QMP is available; but then we risk the
> command line subtly changing and breaking someone else that was using
> the command line without QMP.  Maybe the safest approach is to just use
> the 'x-' prefix to the command line portion, until the feature is complete.
> 

The semantics here are exactly the same as for block devices. The
command line options added to -fsdev are the very same already used
by -drive for years.

Patch 2/2 in this series even factors them out to a common header file
to be used by fsdev and blockdev. I really don't expect any modification
at all on the command line (nor the other people who reviewed that patch
obviously)... are you suggesting that we should put 2/2 on hold and
use the 'x-' prefix anyway ?

Cheers.

--
Greg

Attachment: pgpLX2plNzRyt.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]