[PATCH v2 4/6] docs/about/deprecated: Deprecate the qemu-system-arm binary

Thomas Huth thuth at redhat.com
Fri Mar 3 07:36:22 UTC 2023


On 02/03/2023 23.16, Philippe Mathieu-Daudé wrote:
> On 2/3/23 17:31, Thomas Huth wrote:
>> qemu-system-aarch64 is a proper superset of qemu-system-arm,
>> and the latter was mainly still required for 32-bit KVM support.
>> But this 32-bit KVM arm support has been dropped in the Linux
>> kernel a couple of years ago already, so we don't really need
>> qemu-system-arm anymore, thus deprecated it now.
>>
>> Signed-off-by: Thomas Huth <thuth at redhat.com>
>> ---
>>   docs/about/deprecated.rst | 10 ++++++++++
>>   1 file changed, 10 insertions(+)
>>
>> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
>> index a30aa8dfdf..21ce70b5c9 100644
>> --- a/docs/about/deprecated.rst
>> +++ b/docs/about/deprecated.rst
>> @@ -45,6 +45,16 @@ run 32-bit guests by selecting a 32-bit CPU model, 
>> including KVM support
>>   on x86_64 hosts. Thus users are recommended to reconfigure their systems
>>   to use the ``qemu-system-x86_64`` binary instead.
>> +``qemu-system-arm`` binary (since 8.0)
>> +''''''''''''''''''''''''''''''''''''''
>> +
>> +``qemu-system-aarch64`` is a proper superset of ``qemu-system-arm``. The
>> +latter was mainly a requirement for running KVM on 32-bit arm hosts, but
>> +this 32-bit KVM support has been removed some years ago already (see:
> 
> s/some/few/?

I can also use "three years ago" since the patch had been merged in March 2020.

>> +https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=541ad0150ca4 
>>
>> +). Thus the QEMU project will drop the ``qemu-system-arm`` binary in a
>> +future release. Use ``qemu-system-aarch64`` instead.
> 
> If we unify, wouldn't it be simpler to name the single qemu-system
> binary emulating various ARM architectures as 'qemu-system-arm'?

That would be more intuitive for people who are completely new to QEMU, but 
I guess it will cause a lot of "you broke my script that uses the -aarch64 
binary" troubles again. So I think it's likely better to not go down that road.

  Thomas



More information about the libvir-list mailing list