[Top][All Lists]

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

Re: Making QEMU easier for management tools and applications

From: Markus Armbruster
Subject: Re: Making QEMU easier for management tools and applications
Date: Mon, 13 Jan 2020 14:44:00 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

"Dr. David Alan Gilbert" <address@hidden> writes:

> * Markus Armbruster (address@hidden) wrote:
>> Stefan Hajnoczi <address@hidden> writes:
>> > 4. Go and Rust bindings would also be useful.  There is
>> > https://github.com/intel/govmm but I think it makes sense to keep it
>> > in qemu.git and provide an interface similar to our Python modules.
>> Mapping QAPI/QMP commands and events to function signatures isn't hard
>> (the QAPI code generator does).  Two problems (at least):
>> 1. Leads to some pretty ridiculous functions.  Here's one:
>>     void qmp_blockdev_mirror(bool has_job_id, const char *job_id,
>>                              const char *device,
>>                              const char *target,
>>                              bool has_replaces, const char *replaces,
>>                              MirrorSyncMode sync,
>>                              bool has_speed, int64_t speed,
>>                              bool has_granularity, uint32_t granularity,
>>                              bool has_buf_size, int64_t buf_size,
>>                              bool has_on_source_error,
>>                              BlockdevOnError on_source_error,
>>                              bool has_on_target_error, BlockdevOnError 
>> on_target_error,
>>                              bool has_filter_node_name, const char 
>> *filter_node_name,
>>                              bool has_copy_mode, MirrorCopyMode copy_mode, 
>>                              bool has_auto_finalize, bool auto_finalize,
>>                              bool has_auto_dismiss, bool auto_dismiss,
>>                              Error **errp);
> Those might not be as bad when mapped to other languages, all the
> bool/value pairs would become Option<...>  so that removes that doubling.
> The Error ** mechanism should somehow map onto functions returning a
> normal Rust Result<> type.

Fifteen parameters even with the has_FOO and the errp dropped.
Still ridiculous enough for me.

reply via email to

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