Am 13.10.2021 um 17:30 hat Michael S. Tsirkin geschrieben: > On Fri, Oct 08, 2021 at 03:34:27PM +0200, Kevin Wolf wrote: > > It's still a long way until we'll have QAPIfied devices, but there are > > some improvements that we can already make now to make the future switch > > easier. > > > > One important part of this is having code paths without QemuOpts, which > > we want to get rid of and replace with the keyval parser in the long > > run. This series adds support for JSON syntax to -device, which bypasses > > QemuOpts. > > > > While we're not using QAPI yet, devices are based on QOM, so we already > > do have type checks and an implied schema. JSON syntax supported now can > > be supported by QAPI later and regarding command line compatibility, > > actually switching to it becomes an implementation detail this way (of > > course, it will still add valuable user-visible features like > > introspection and documentation). > > > > Apart from making things more future proof, this also immediately adds > > a way to do non-scalar properties on the command line. nvme could have > > used list support recently, and the lack of it in -device led to some > > rather unnatural solution in the first version (doing the relationship > > between a device and objects backwards) and loss of features in the > > following. With this series, using a list as a device property should be > > possible without any weird tricks. > > > > Unfortunately, even QMP device_add goes through QemuOpts before this > > series, which destroys any type safety QOM provides and also can't > > support non-scalar properties. This is a bug, but it turns out that > > libvirt actually relies on it and passes only strings for everything. > > So this series still leaves device_add alone until libvirt is fixed. > > > Reviewed-by: Michael S. Tsirkin <mst@xxxxxxxxxx> > > I assume you are merging this? Yes, I can merge it through my tree. Thanks for the review! Kevin
