Message ID | 20201002133923.1716645-1-philmd@redhat.com (mailing list archive) |
---|---|
Headers | show |
Series | qapi: Restrict machine (and migration) specific commands | expand |
Philippe Mathieu-Daudé <philmd@redhat.com> writes:
> Reduce the machine code pulled into qemu-storage-daemon.
I'm leaving review to Eduardo and Marcel for PATCH 1-4, and to David and
Juan for PATCH 5. David already ACKed.
Can do the pull request.
On 05/10/20 10:01, Markus Armbruster wrote: > Philippe Mathieu-Daudé <philmd@redhat.com> writes: > >> Reduce the machine code pulled into qemu-storage-daemon. > I'm leaving review to Eduardo and Marcel for PATCH 1-4, and to David and > Juan for PATCH 5. David already ACKed. > > Can do the pull request. > If it counts, :) for patch 1-4: Acked-by: Paolo Bonzini <pbonzini@redhat.com> Generally these patches to remove code from user-mode emulators fall into the "if it builds it's fine" bucket, since I assume we want the "misc" subschema to be as small as possible. Paolo
Paolo Bonzini <pbonzini@redhat.com> writes: > On 05/10/20 10:01, Markus Armbruster wrote: >> Philippe Mathieu-Daudé <philmd@redhat.com> writes: >> >>> Reduce the machine code pulled into qemu-storage-daemon. >> I'm leaving review to Eduardo and Marcel for PATCH 1-4, and to David and >> Juan for PATCH 5. David already ACKed. >> >> Can do the pull request. >> > > If it counts, :) for patch 1-4: > > Acked-by: Paolo Bonzini <pbonzini@redhat.com> > > Generally these patches to remove code from user-mode emulators > fall into the "if it builds it's fine" bucket, since I assume > we want the "misc" subschema to be as small as possible. Moving stuff out of qapi/misc.json is good as long as the new home makes sense. So, if it builds *and* the maintainers of the new home think it makes sense to have it there, it's fine. I don't think we should aim for eliminating every last bit of unused generated code from every program. We should aim for a sensible split into sub-modules. Unused generated code in a program can be a sign for a less than sensible split.