On Fri, Oct 23, 2020 at 12:12:16PM +0200, Kevin Wolf wrote: > While the qemu-storage-daemon command line is still considered unstable, > let's change --chardev from the old QemuOpts-based parser to QAPI, so > that it becomes a simple mapping of chardev-add to the command line and > will fit in a future fully QAPIfied command line without later > incompatible changes or additional compatibility glue.
NB, I am *not* objecting to this series in what I'm about to write, but I want to point out that I don't think we should assume that this proposed QAPIified CLI is neccessarily the long term end point. Below I outline potential incompatible changes that would end up turning -chardev into legacy / deprecated syntax. The chardev QAPI-ification is a good example of the gap between QOM and QAPI. The chardev backends are QOM classes, but they lack the "user creatable" interface. Thus instead of configuring them using -object / object_add, we have a QAPI model, custom args/commands -chardev / chardev_add, and then code that populates the object instance properties from the QAPI model. Except we've not really exposed them as object instance properties - they are mostly just struct fields directly accessed. The benefit of the chardev approach is that we have an introspectable QAPI model. The downside is that we have a bunch of conversion code for QAPI to QOM mapping. The benefit of the user creatable object approach is that we dont have to add custom CLI args for different types of object, nor write code to populate QOM from QAPI. The downside is that we're divorced from the QAPI schema, so loose introspection, and have a different type of tedious boilerplate code to write. The fact that we have this custom -chardev arg, instead of just using -object is related to the ordering problems we have in main() in the system emulators. We have some -object types that need creating before the chardev types, and some -object types that need creating after the chardevs. If -chardev didn't exist, and we used -object for chardev creation, then the ordering problem would trivially not exist, as we would simply be processing all -object args in order that we receive them. IOW, if we're considering our ideal long term configuration goals for QEMU, then I think we should be looking at a solution to bridge the gap, so that we can get the best of both worlds, and have a single way todo things. IMHO, ideally none of -netdev, -chardev, -device, etc would exist in any "modern" CLI, they would just be considered legacy syntax. Essentially everything would be created using the same -object arg and object_add commands. What I think this means is that we need to use QAPI to represent the properties of an object, and auto-generate the QOM code to register properties, provider setters/getters, constructors, etc. For existing user creatable objects this would largely involve deleting lots of existing code and defining some simple QAPI schemas. This is probably quite easy, if tedious. For the chardev/netdev/etc objects we already have the QAPI schema, but would need to add code genration parts to turn them into full user creatable object classes. This is likely harder more involved work, especially to keep backcompat working well. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
