On Mon, Mar 21, 2022, 11:29 AM Eric Blake <ebl...@redhat.com> wrote: > On Fri, Mar 18, 2022 at 04:36:46PM -0400, John Snow wrote: > > Rework qemu_io() to be analogous to qemu_img(); a function that requires > > a return code of zero by default unless disabled explicitly. > > > > Tests that use qemu_io(): > > 030 040 041 044 055 056 093 124 129 132 136 148 149 151 152 163 165 205 > > 209 219 236 245 248 254 255 257 260 264 280 298 300 302 304 > > image-fleecing migrate-bitmaps-postcopy-test migrate-bitmaps-test > > migrate-during-backup migration-permissions > > > > Test that use qemu_io_log(): > > 242 245 255 274 303 307 nbd-reconnect-on-open > > > > Signed-off-by: John Snow <js...@redhat.com> > > > > --- > > > > Note: This breaks several tests at this point. I'll be fixing each > > broken test one by one in the subsequent commits. We can squash them all > > on merge to avoid test regressions. > > > > (Seems like a way to have your cake and eat it too with regards to > > maintaining bisectability while also having nice mailing list patches.) > > Interesting approach; it does appear to have made reviewing a bit > easier, so thanks for trying it. > > I'll withhold actual R-b until the last squashed patch, but so far, I > haven't seen anything that causes me grief other than the lack of > bisectability that you already have documented how it will be > addressed. [less wordy - this patch is incomplete, as advertised, but > looks good] >
Meta chat about QEMU patch process: I have to admit that I often "work backwards" and I prototype things by just making a function behave like how I want it to, and then I try and measure how many things broke post-hoc and use that to decide if the refactoring is even tractable. Often the slowest part of writing a series for me is breaking apart the "WIP" commit into a series of smaller steps that don't break the bisect. Sometimes this even involves a complete rewrite of an intermediate data structure to handle the in-between step. It feels like a lot of work just to delete it several commits later, sometimes. I realize giant merge commits are tough to backport, but sometimes I really just get stumped on how to not create twice as much work for myself just to arrive at an end point I've already arrived at. Of course, making things like this reviewable is a primary concern too. I'm not sure I'm an advocate of the squash-on-merge school of thought entirely, but maybe it's not so bad to use it sparingly, sometimes. I find keeping mini-commits separate can sometimes help me iterate on the design of a series quicker, too. In this case, I did try to position fixes that would work independently of the switch ahead of the pivot, but I couldn't quite get everything. Most of what's left is really just cases where the return type matters. Eh. This is definitely "Software Engineering" and not "Computer Science". Thanks for taking a look. > -- > Eric Blake, Principal Software Engineer > Red Hat, Inc. +1-919-301-3266 > Virtualization: qemu.org | libvirt.org > >
