[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v6 0/2] allow blockdev-add for NFS

From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH v6 0/2] allow blockdev-add for NFS
Date: Thu, 19 Jan 2017 16:42:02 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Am 19.01.2017 um 16:34 hat Peter Lieven geschrieben:
> Am 19.01.2017 um 16:20 schrieb Kevin Wolf:
> >Am 19.01.2017 um 15:59 hat Eric Blake geschrieben:
> >>On 01/19/2017 08:30 AM, Peter Lieven wrote:
> >>>>>qemu-img: Could not open
> >>>>>'nfs://,linux?readahead=131072':
> >>>>>Block protocol 'nfs' doesn't support the option 'readahead-size'
> >>>>>
> >>>>>Please let me know if the below fix would be correct:
> >>>>No, this needs to be fixed the other way round: runtime_opts must use
> >>>>the names as specified in the schema, and nfs_client_open() must access
> >>>>them as such. Without that, blockdev-add can't work (and the command
> >>>>line only with the "wrong" old option names from the URL, whereas it
> >>>>should be using the same names as the QAPI schema).
> >>>Shouldn't we support both for backwards compatiblity.?
> >>blockdev-add only needs to support the modern naming.  But yes,
> >>preserving back-compat spelling of the command-line spellings, as well
> >>as matching blockdev-add spellings, is desirable.
> >We only just added the individual command line options, previously it
> >only supported the URL.
> >
> >It's true that we have the messed up version of the options in 2.8, so
> >strictly speaking we would break compatibility with a release, but it's
> >only one release, it's only the nfs driver, and the documentation of the
> >options is the schema, which had the right option names even in 2.8
> >(they just didn't work).
> >
> >So I wouldn't feel bad about removing the wrong names in this specific
> >case.
> So want exactly do you want to do? Fix the names in the QAPI schema
> to use the old naming?

No, fix the command line to use the names in the QAPI schema.

The option names from the URL were never supposed to be supported on the
command line.


reply via email to

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