Il 27/11/2013 18:02, Markus Armbruster ha scritto: > I have to admit I can't tell offhand what the heck QMP's netdev_add > accepts, because I don't understand what "'*props:': '**'" means in > qapi-schema.json. Even today, we permit code to serve as documentation > and specification for new features. I wish we didn't.
It is ignored, because qmp_netdev_add does not use an automatically-generated unmarshaler. > Anyway, whatever it parses ends up in a QDict, as usual. The QDict comes straight from the monitor dispatch. It is the QDict that ordinarily would be unmarshaled by automatically-generated code. > The part that sucks is the use of QemuOpts as netdev_add() parameter, > > It made some sense when it was done, because then the command line was > the only user, its data type for option parameters was (and is) > QemuOpts, and QemuOpts was the least inconvenient way to do a function > that wants a a discriminated union of parameters, like netdev_add does. > > It stopped making sense when we started using it from QMP, whose data > type for parameters is QDict. I shoehorned netdev_add into QMP in its > early days. Hinsight 20/20... Yes. > In my opinion, use of QemuOpts for anything but parsing parameter > strings has become a mistake. Yes. OTOH QemuOpts is the only reason why QMP and HMP can use a common back-end (netdev_add). With object-add you don't use QemuOpts (for good reasons: you want to separate the human-oriented parsing and the JSON-oriented parsing) and thus you need separate code for QMP and HMP---at least for now. The HMP code can use QemuOpts just like vl.c. The QMP code would use qdict_iter or qdict_first/next and call object_set_property for each element of the dictionary. > Laszlo converted net.c to saner internal interfaces (commit > d195325..1a0c095). Perhaps we can build on that. Yeah, that could be an idea. Another is to convert netdevs to QOM (reusing Laszlo's data structures of course) and then just use object-add and -object. Paolo
