Re: Insufficiently documented deprecated command arguments

[Markus Armbruster]

Peter Krempa <address@hidden> writes:

> On Wed, Dec 11, 2019 at 12:32:10 +0000, Daniel Berrange wrote:
>> On Wed, Dec 11, 2019 at 01:24:17PM +0100, Kevin Wolf wrote:
>> > Am 11.12.2019 um 11:51 hat Peter Krempa geschrieben:
>> > > On Wed, Dec 11, 2019 at 11:14:39 +0100, Kevin Wolf wrote:
>
> [...]
>
>> > > Well, in some specific cases we could detect the node names
>> > > auto-assigned by qemu and use them instead of paths, but in my opinion
>> > > it's not worth the effort and extra code.
>> > 
>> > Well, the question is what to do on the QEMU side then. Deprecation
>> > should mean that we have a plan for removing the feature. If we're
>> > planning to keep the feature indefinitely because libvirt needs it, we
>> > might want to consider removing the deprecation notice.
>> 
>> Ideally libvirt would stop using -drive entirely, as I hate the idea of
>> having to keep this around indefinitely in libvirt too. This needs QEMU
>> to close the last gaps wrt SD cards
>
> Yes and also give us guidance how to convert it. Looking at the code
> didn't help. There's a plethora of controllers and options to configure
> without clear indication what is default behaviour expected.

Similar situation as for if=pflash.  That one we addressed just for
"tier 1" machine types: i386 pc-*, arm virt-*.

Would addressing if=sd just for these machines suffice?

Addressing if=pflash and if=sd for all machines looks is beyond my
capacity.

For a more detailed analysis, see my "Review of onboard block device
configuration with -drive", Message-ID:
<address@hidden>.  Relevant parts:

    The interface types are:
    [...]
    * if=pflash

      Many machines have onboard pflash devices.  They recognize
      bus=0,unit=U where 0 <= U < number of such onboard devices.  ARM
      machine sbsa-ref, virt, i386 machines pc*, isapc, xenfv, Risc-V
      machine virt provide machine properties for connecting backends to
      their onboard pflash devices.  For the other machines, -drive is still
      the only way to connect backends.

      PPC machines pseries* create spapr-nvram devices instead.  It can be
      created with -device instead.

      SPARC machine niagara creates a memory region instead *boggle*.
      -drive is the only way to configure that.

      Other machines create the onboard pflash device only when the
      corresponing drive is present.  Since pflash devices are not
      pluggable, -drive is the only way to create them.
    [...]
    * if=sd

      Many machines have onboard sd-card devices.  They recognize
      bus=0,unit=U where 0 <= U < number of such onboard devices.  -drive is
      the only way to connect backends.
    [...]

    Summary
    [...]
    * if=pflash, if=mtd and if=sd are blocked by the "no way to connect
      backends to onboard devices" issue, and the "no way to create the
      device" issue.  We solved them for if=pflash with some boards.  Many
      more remain.

> Trying to convert it blindly would end up worse than just ditching
> support for sdcards altogehter.

Tempting, isn't it?