Deprecation of the LM32 target

Deprecation of the LM32 target

[John Paul Adrian Glaubitz]

Hello!

I was just browsing through the QEMU Christmas Calendar [1] and noticed
the announcement for the deprecation of the LM32 target.

I'm not sure what the motivation of the deprecation is, but isn't one of
the big selling points of QEMU to support deprecated targets?

If QEMU eventually ends up supporting commercially available targets only
and kicking out everything that is obsolete, I'm not sure what the point
of QEMU would be in the first place as products like VMWare and VirtualBox
already provide virtualization functionality.

Please don't deprecate targets just because they're old.

Thanks,
Adrian

> [1] https://www.qemu-advent-calendar.org/2020/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Deprecation of the LM32 target

[Thomas Huth]

On 24/12/2020 10.53, John Paul Adrian Glaubitz wrote:
> Hello!
> 
> I was just browsing through the QEMU Christmas Calendar [1] and noticed
> the announcement for the deprecation of the LM32 target.
> 
> I'm not sure what the motivation of the deprecation is, but isn't one of
> the big selling points of QEMU to support deprecated targets?
> 
> If QEMU eventually ends up supporting commercially available targets only
> and kicking out everything that is obsolete, I'm not sure what the point
> of QEMU would be in the first place as products like VMWare and VirtualBox
> already provide virtualization functionality.
> 
> Please don't deprecate targets just because they're old.

  Hi,

the problem is not that the target CPU is old, but rather that according to 
the (former?) maintainer, there are no users left:

  https://www.mail-archive.com/qemu-devel@nongnu.org/msg605024.html

So it got marked as deprecated in this commit here:

  https://git.qemu.org/?p=qemu.git;a=commitdiff;h=d84980051229fa43c96b3

Without maintainer and without users, there is no point in keeping this 
target, is there?

  Thomas

Re: Deprecation of the LM32 target

[John Paul Adrian Glaubitz]

Hello!

On 12/26/20 9:39 AM, Thomas Huth wrote:
> the problem is not that the target CPU is old, but rather that according to the (former?) maintainer, there are no users left:
> 
>  https://www.mail-archive.com/qemu-devel@nongnu.org/msg605024.html
> 
> So it got marked as deprecated in this commit here:
> 
>  https://git.qemu.org/?p=qemu.git;a=commitdiff;h=d84980051229fa43c96b3
> 
> Without maintainer and without users, there is no point in keeping this target, is there?

I'm not sure how you determine whether there are people using the code or not. There
is no really user tracking in QEMU, is there?

And the maintainer's claim that RISC-V takes over makes no sense either. The point of
emulators is to be able to run old and existing software. If a target had only a
justification to exist while it's commercially viable, you would have to remove 90%
of the targets in QEMU.

I mean, the whole point of an emulator is being able to run existing code on modern hardware,
usually because the old hardware is no longer available. And as long as the target is
functional, I don't see a point in taking away the functionality.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Deprecation of the LM32 target

[Michael Walle]

Hi,

Am 2020-12-26 10:06, schrieb John Paul Adrian Glaubitz:
> Hello!
> 
> On 12/26/20 9:39 AM, Thomas Huth wrote:
>> the problem is not that the target CPU is old, but rather that 
>> according to the (former?) maintainer, there are no users left:
>> 
>>  https://www.mail-archive.com/qemu-devel@nongnu.org/msg605024.html
>> 
>> So it got marked as deprecated in this commit here:
>> 
>>  https://git.qemu.org/?p=qemu.git;a=commitdiff;h=d84980051229fa43c96b3
>> 
>> Without maintainer and without users, there is no point in keeping 
>> this target, is there?
> 
> I'm not sure how you determine whether there are people using the code
> or not. There
> is no really user tracking in QEMU, is there?

That is correct, one cannot know if there are actually users of the
milkymist board or the lattice eval board. These are the two only
supported boards. The (or I should better say "my") main purpose to
add a qemu target for milkymist was to help the developers of the
board, e.g. to ease debugging, etc. But development has stopped
long time ago [1]. I've never seen a request to add a new board.

> And the maintainer's claim that RISC-V takes over makes no sense
> either.

I've meant the ecosystem around the SoC. LM32 on linux never took of,
mostly because there is no MMU (we've worked on one though). There is
no official lm32 support in linux and g++ support is broken (or never
even worked). While for RISC-V there is huge userbase building all sorts
of tooling.

There is a project called LiteX [2], some sort of toolbox to build your
own SoC, which supports the LM32 as a CPU component. But I've never seen
anyone trying to add a board to qemu.

> The point of
> emulators is to be able to run old and existing software. If a target 
> had only a
> justification to exist while it's commercially viable, you would have
> to remove 90% of the targets in QEMU.
> I mean, the whole point of an emulator is being able to run existing
> code on modern hardware,
> usually because the old hardware is no longer available. And as long
> as the target is
> functional, I don't see a point in taking away the functionality.

I'm not arguing against this. In fact, I'd also like to keep the lm32
qemu target, but I personally don't have any time for that anymore. And
I don't know if its fair to put the burdon of unmaintained boards to all
the qemu developers. There are a lot of test cases for the LM32
target, but these only cover the CPU instructions. The last time I've
looked audio was broken. So without anyone caring about the target, it
won't also be much help for the user either.

-michael

[1] 
https://github.com/m-labs/milkymist/commit/7d944d3dcffb5e528a44937b10123ff65a0aecbc
[2] https://github.com/enjoy-digital/litex

Re: Deprecation of the LM32 target

[Thomas Huth]

On 26/12/2020 10.06, John Paul Adrian Glaubitz wrote:
> Hello!
> 
> On 12/26/20 9:39 AM, Thomas Huth wrote:
>> the problem is not that the target CPU is old, but rather that according to the (former?) maintainer, there are no users left:
>>
>>   https://www.mail-archive.com/qemu-devel@nongnu.org/msg605024.html
>>
>> So it got marked as deprecated in this commit here:
>>
>>   https://git.qemu.org/?p=qemu.git;a=commitdiff;h=d84980051229fa43c96b3
>>
>> Without maintainer and without users, there is no point in keeping this target, is there?
> 
> I'm not sure how you determine whether there are people using the code or not. There
> is no really user tracking in QEMU, is there?
> 
> And the maintainer's claim that RISC-V takes over makes no sense either. The point of
> emulators is to be able to run old and existing software. If a target had only a
> justification to exist while it's commercially viable, you would have to remove 90%
> of the targets in QEMU.
> 
> I mean, the whole point of an emulator is being able to run existing code on modern hardware,
> usually because the old hardware is no longer available. And as long as the target is
> functional, I don't see a point in taking away the functionality.

You also have to consider that it takes some effort to keep code up to date, 
e.g. if there is a bigger restructuring of the code base going on, you also 
have to work on neglected targets, too. If there is no active maintainer 
left anymore, it's quite a burden for all the other developers.
So if there is no known user left (are *you* using lm32?), and there is no 
active maintainer anymore, it's IMHO adequate to mark a target as 
deprecated. If someone still wants to run old lm32 code, they still can use 
older versions of QEMU to do this.

  Thomas

Re: Deprecation of the LM32 target

[Peter Maydell]

On Tue, 29 Dec 2020 at 10:38, Thomas Huth <thuth@redhat.com> wrote:
> On 26/12/2020 10.06, John Paul Adrian Glaubitz wrote:
> > I mean, the whole point of an emulator is being able to run existing code on modern hardware,
> > usually because the old hardware is no longer available. And as long as the target is
> > functional, I don't see a point in taking away the functionality.
>
> You also have to consider that it takes some effort to keep code up to date,
> e.g. if there is a bigger restructuring of the code base going on, you also
> have to work on neglected targets, too. If there is no active maintainer
> left anymore, it's quite a burden for all the other developers.
> So if there is no known user left (are *you* using lm32?), and there is no
> active maintainer anymore, it's IMHO adequate to mark a target as
> deprecated.

Right, the issue is not that the hardware being emulated is old,
it's that the code in QEMU to do that emulation is old and there's
no active maintainer for it and nobody helping to keep it up to
date with the rest of QEMU and its evolving APIs and practices.
"And we don't think there are likely to be any serious users either"
is just the cherry on the cake...

> If someone still wants to run old lm32 code, they still can use
> older versions of QEMU to do this.

Or they could put in the work to be the maintainer :-)

thanks
-- PMM