qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v6 16/18] xen: automatically create XenBlockDevi


From: Paul Durrant
Subject: Re: [Qemu-devel] [PATCH v6 16/18] xen: automatically create XenBlockDevice-s
Date: Wed, 19 Dec 2018 14:03:34 +0000

> -----Original Message-----
> From: Anthony PERARD [mailto:address@hidden
> Sent: 19 December 2018 14:01
> To: Paul Durrant <address@hidden>
> Cc: address@hidden; address@hidden; xen-
> address@hidden; Kevin Wolf <address@hidden>; Max Reitz
> <address@hidden>; Stefano Stabellini <address@hidden>
> Subject: Re: [PATCH v6 16/18] xen: automatically create XenBlockDevice-s
> 
> On Wed, Dec 19, 2018 at 12:43:24PM +0000, Paul Durrant wrote:
> > > Kevin seems to say that this could be done without the _flat_confused
> > > version. The flat_confused version seems to be useful just because
> > > the key "cache.direct" is used earlier, and because everything in
> qdict
> > > is a string.
> >
> > It could be, but there's a good reason for wanting everything as a
> string, and that is so that I can do a qdict_iter to generate my trace
> message. Also I really don't want to get too elaborate here... this is
> supposed to be mimicking what would normally come via a json blob, and
> that would start out as strings.
> 
> Mimic JSON ? Not really. JSON has types. If the toolstack wanted
> cache.direct or read-only option on a blockdev, it will need to use the
> bool type as string type will be rejected.  The expected types when
> issuing a QMP request can be found in "qapi/block-core.json", for the
> command "blockdev-add".
> 
> Also, there is a comment on the qobject_input_visitor_new_flat_confused
> function, it reads:
>     The block subsystem uses this function to visit its flat QDict with
>     possibly confused scalar types.  It should not be used for anything
>     else, and it should go away once the block subsystem has been
>     cleaned up.
> 
> We might as well avoid using it right now, as it's easy to do so.

Ah, I'd not noticed that comment. In that case, yes it should be avoided.

  Paul

> 
> --
> Anthony PERARD



reply via email to

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