qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v3 07/10] qapi: implement conditional command arguments


From: Markus Armbruster
Subject: Re: [PATCH v3 07/10] qapi: implement conditional command arguments
Date: Thu, 02 Mar 2023 12:09:36 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Thu, Mar 02, 2023 at 07:58:28AM +0100, Markus Armbruster wrote:
>> Marc-André Lureau <marcandre.lureau@gmail.com> writes:
>> 
>> > Hi
>> >
>> > On Wed, Mar 1, 2023 at 5:16 PM Markus Armbruster <armbru@redhat.com> wrote:
>> >> What about 3. have an additional command conditional on CONFIG_WIN32?
>> >> Existing getfd stays the same: always fails when QEMU runs on a Windows
>> >> host.  The new command exists only when QEMU runs on a Windows host.
>> 
>> We could additionally deprecate getfd for Windows.
>> 
>> > This is what was suggested initially:
>> > https://patchew.org/QEMU/20230103110814.3726795-1-marcandre.lureau@redhat.com/20230103110814.3726795-9-marcandre.lureau@redhat.com/
>> >
>> > I also like it better, as a specific command for windows sockets, less
>> > ways to use it wrongly.
>> 
>> Daniel, what do you think?
>
> I wasn't especially a fan of platform specific APIs, but perhaps in
> retrospect it will be the lesser of two evils.

Marc-André, let's go to your initial approach then.

This breaks the dependence between this patch and the remainder of the
series.

We still need to consider this patch anyway.  It partially fills gaps in
code generation for unboxed conditional arguments.  Partially, because
the last argument must not be conditional.  It needs work to either lift
this restriction, or reject such arguments properly.  Either way, the
generated code will be ugly, and the handwritten code interfacing with
it will be ugly, too.

I'd like to tighten the restriction instead: conditional arguments
require boxed.  Less ugly and less awkward to document, I think.




reply via email to

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