Re: [Qemu-devel] Maintainers, please tell us how to boot your machines!

[Markus Armbruster]

Philippe Mathieu-Daudé <address@hidden> writes:

> '
> On Tue, Mar 12, 2019 at 6:44 PM Markus Armbruster <address@hidden> wrote:
>>
>> Dear board code maintainers,
>>
>> This is a (rather late) follow-up to the last QEMU summit.  Minutes[*]:
>>
>>  * Deprecating unmaintained features (devices, targets, backends) in QEMU
>>
>>    QEMU has a mechanism to deprecate features but there remains a lot of
>>    old unmaintained code.  Refactoring is hindered by untested legacy
>>    code, so there is a desire to deprecate unmaintained features more
>>    often.
>>
>>    [...]
>>
>>    We should require at least a minimal test for each board; if nobody
>>    cares enough to come up with one, that board should be deprecated.
>>
>>    [...]
>>
>>    Also see the qemu-devel discussion about deprecating code:
>>    https://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg05828.html.
>>
>> That's a link to "Minutes of KVM Forum BoF on deprecating stuff".
>> Quote:
>>
>>  * One obvious class of candidates for removal is machines we don't know
>>    how to boot, or can't boot, say because we lack required firmware
>>    and/or OS.
>
> IIRC there is still a legal issue with some firmwares we don't have
> the sources. What is your idea here, ask the maintainer to run his
> tests and expect a manual confirmation, else deprecate?

Meaningful tests may require

(1) Parts we can distribute (i.e. they're free as in freedom)

(2) Parts we can download

(3) Parts only a privileged person (better be the maintainer) has

(4) Unobtanium

Tests requiring (1) or (2) can be automated.

For tests requiring (3), we can ask the privileged person to certify.
Whether the QEMU project is interested in maintaining such machines is
up to the project to decide.

Tests requiring (4) would be dead code.  The QEMU project maintaining
machines the project can't meaningfully test makes no sense.

>>    Of course, "can boot" should be an automated test.  As a first step
>>    towards that, we should at least document how to boot each machine.
>>    We're going to ask machine maintainers to do that.
>>
>> Let's get going on this.
>>
>> I gathered the machine types, mapped them to source files, which I fed
>> to get_maintainer.pl.  Results are appended.  If you're cc'ed,
>> MAINTAINERS fingers you for at least one machine type's source file.
>> Please tell us for all of them how to to a "meaningful" boot test.
>
> This is a good start, but the -cpu option is important too.
>
> Example: nanoMIPS
>
> files:
> https://mipsdistros.mips.com/LinuxDistro/nanomips/buildroot/index.html
>
> qemu-system-mipsel -M malta -serial stdio -cpu I7200  -append
> "mem=256m@@0x0 rw console=ttyS0" -kernel
> generic_nano32r6el_page64k_dbg

One reason I asked for complete QEMU command lines :)

Covering the full cartesian product machine type × cpu type would be
better, but let's start small.

>> For now, what's "meaningful" is entirely up to you.  Booting Linux
>> certainly is.
>>
>> Make sure to include a complete QEMU command line.  If your QEMU command
>> line requires resources beyond the QEMU source tree and what we build
>> from it, please detail them, and provide download URLs as far as
>> possible.
>>
>> Goals for this exercise:
>>
>> * Gather information we need to cover more machines in our automated
>>   testing.
>>
>>   Related work:
>>   [PATCH v4 00/19] Acceptance Tests: target architecture support
>>   Message-Id: <address@hidden>
>>   https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg03881.html
>>
>> * Maybe identify a few machines we don't know how to boot anymore.
>>
>> Thanks in advance for your help!
[...]