[Top][All Lists]

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

Re: [RFC PATCH 08/18] qemu-storage-daemon: Add --export option

From: Max Reitz
Subject: Re: [RFC PATCH 08/18] qemu-storage-daemon: Add --export option
Date: Wed, 6 Nov 2019 14:39:32 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1

On 06.11.19 14:34, Kevin Wolf wrote:
> Am 06.11.2019 um 14:11 hat Max Reitz geschrieben:
>> On 17.10.19 15:01, Kevin Wolf wrote:
>>> Add a --export option to qemu-storage-daemon to export a block node. For
>>> now, only NBD exports are implemented. Apart from the 'type' option
>>> (which is the implied key), it maps the arguments for nbd-server-add to
>>> the command line. Example:
>>>     --export nbd,device=disk,name=test-export,writable=on
>>> Signed-off-by: Kevin Wolf <address@hidden>
>>> ---
>>>  qapi/block.json       | 27 +++++++++++++++++++++++++++
>>>  qemu-storage-daemon.c | 31 +++++++++++++++++++++++++++++++
>>>  2 files changed, 58 insertions(+)
>> Would it be better to collect the BlockExports in a list and work on it
>> after all arguments have been parsed?  As it is, it’s important that
>> users define block devices and things like NBD servers before --export.
>>  Yes, I know, that’s exactly how it works with qemu, but is that really
>> the best way?
> It's actually not how QEMU works generally. QEMU collects things in
> QemuOptsLists and then tries to interpret them in the right order. Of
> course, we never get the order actually right, which results in constant
> reshuffling of the order of initialisations in vl.c.
> It also means that vl.c (!) has a list of -object types that need to be
> created early so that other backends can make use of them, and of those
> types that actually depend on a backend already being present (see
> object_create_initial() for details).
> I think it's much cleaner to simply use the order in the command line
> instead of adding magic that tries to resolve (and fails at actually
> resolving) all the dependencies. I seem to remember that this was in
> fact one of the things Markus keeps mentioning he would change if he
> were to rewrite the QEMU command line parser from scratch without
> compatibility requirements.



Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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