Re: [Qemu-devel] Large patch set advice

[Peter Maydell]

On 30 April 2018 at 15:44, Warner Losh <address@hidden> wrote:
> The testing aspect has me intrigued. How hard would it be to add testing
> done for bsd-user to your upstream tests? Before this project, I've only
> ever been a qemu user, and even then only around the edges so I'm not
> familiar with what's available. For the sake of argument, you can assume
> FreeBSD has its own testbed we use, some useful subset of which could be
> leveraged into an extended unit test.

The problem we've traditionally had is that when you're building
and testing qemu on host architecture A, you can't guarantee to
have a suitable cross building environment for architecture B
so that you can build the test guest executables you want to run
under QEMU to test whether qemu-B works. (For linux-user we're
currently looking at using docker to provide consistent working cross
environments, but that is work-in-progress.)

> Finally, another poster suggested that delete and repopulate would be an
> option. While I haven't made any final decisions on whether I want to go
> that way, I'd like to know from Peter if he would accept things that way. I
> think it may be easier for me to submit something like that, but on the
> other hand the boiling the patches down even from 300 to 190 (where the work
> stands at the moment) has identified some interesting issues I need to chase
> down (mostly relating to either inappropriate for upstreaming patches mixed
> in, or relating to what looks like a mismerge a few months ago due to git +
> long-lived-branch + merges having... I'll be nice and say 'challenges when
> changes collide').

If we definitely don't care about the current functionality of upstream
for any of the BSDs (and it sounds like we don't -- thanks for looking
into that), then I think the main concern is "what is easiest to code
review". Which approach gives the most digestible patches for code
review probably depends on how much of the existing code and structure
remains after all the changes; that's a judgement call you're probably
in a better position to make. Either way I would still like to see
patches that are each of a reasonable size and provide coherent chunks of
functionality.

thanks
-- PMM