Markus Armbruster <arm...@redhat.com> writes: > Eric Blake <ebl...@redhat.com> writes: > >> It's time to expose QMP 'netdev_add' through introspection, and >> to add boxed commands/events so that we can drastically reduce >> the number of C parameters needed to implement a command that >> matches a large QAPI type. >> >> Prerequistes: >> Markus' qapi-next branch (weak; series also applies on master) >> >> available as a tag at: >> git fetch git://repo.or.cz/qemu/ericb.git qapi-cleanupv9f >> or as part of my qapi branch: >> git fetch git://repo.or.cz/qemu/ericb.git qapi >> >> v8 was here: >> https://lists.gnu.org/archive/html/qemu-devel/2016-07/msg00302.html >> >> Since then, I've addressed Markus' comments: >> - s/box/boxed/ >> - fix a useless Python override of c_name() >> - comment and formatting tweaks >> - defer event collision prevention until later; for 2.7, we are >> focusing on the bare minimum needed to take advantage of boxing >> - implement a promised followup that allows netdev_add to still >> parse strings the way it did with QemuOpts (thanks Dan for starting >> that effort) >> >> The diffstat from v8 looks big, but a lot of it is mechanical >> due to the spelling change. It's late at night, and we're close >> to hard freeze, so to maximize review time I'm posting now; if I >> weren't feeling quite as rushed, I might would have swapped the >> order of 14 vs. 15-17 to avoid even a temporary behavior change >> in netdev_add. On the other hand, 14 has had review, while 15-17 >> are effectively new, and it is feasible that we may be comfortable >> enough with the new type-safety constraints of 14 to not want >> to bother with 15-17 loosening things back up, given that we are >> already in soft freeze. > > PATCH 01-13 with the few overlooked instanced of 'box' corrected: > Reviewed-by: Markus Armbruster <arm...@redhat.com>
Pushed to qapi-next with PATCH 11 replaced by your update. > PATCH 14-17 need careful consideration. It's very late in the cycle, > which means there's little time to correct mistakes before they become > ABI. Risks upsetting the release with last minute corrections. Pushed to qapi-not-next for now. > The safest option is to punt to the next cycle. Would be a shame, > though. > > I need to read your discussion of the backward compatibility patches, > and the patches themselves, carefully.