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

[Markus Armbruster]

Kevin Wolf <address@hidden> writes:

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

Seconded.

The "process arguments strictly left to right" strategy is also visible
in PATCH 02 and 05.

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

E.g.
Message-ID: <address@hidden>
https://lists.nongnu.org/archive/html/qemu-devel/2016-09/msg00163.html