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: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH 1/2 v16] fsdev: add IO throttle support to fsdev devices
Date: Tue, 14 Feb 2017 13:21:22 +0000
User-agent: Mutt/1.7.1 (2016-10-04)

On Tue, Feb 07, 2017 at 05:29:33PM +0100, Greg Kurz wrote:
> 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 ?

I see these parameter names as stable.  There is little risk that they
would change.

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

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