Issue 90 Further Clarifications

[image: Dustan Helm] <https://gitlab.com/dustan.helm> Dustan Helm <https://gitlab.com/dustan.helm> @dustan.helm <https://gitlab.com/dustan.helm> · just now <https://gitlab.com/libvirt/libvirt/-/issues/90#note_451306432> <https://gitlab.com/libvirt/libvirt/-/issues/90#> Before we start making changes and solidifying our XML parameter choices, we have a few clarifying questions about the issue we'd like to get out of the way. 1. In src/qemu/qemu_capabilities.h, we found the string "/* -drive file.driver=vxhs via query-qmp-schema */" after the QEMU_CAPS_VXHS declaration. What is the purpose of these strings, and how do we modify them to make sense for nfs? Would we simply mirror what is done for VXHS, adding nfs as the protocol instead? 2. Where is domain XML parsed and formatted? Is that what is referred to by the schema formats in domaincommon.rng? 3. In src/qemu/qemu_block.c, the json object arguments currently present in qemuBlockStorageSourceGetVxHSProps(...) are not the same ones listed in the example commit. What is the reason for this change, and how should we take it into account when implementing a new protocol type? Additionally, we were hoping we could get some clarification on the proper way to handle submitting patches with multiple commits. If we receive feedback for only part of a patch, for example, how would we be meant to update it? Would we simply amend the particular commit that needed updates, and if so, how do we amend a commit other than the most recent commit? Should we send in our patches for review one at a time, or try to get all of them made and then send them in all at once?