[Qemu-devel] Proposal: deprecate and remove QEMU's unicore32 target code

[Qemu-devel] Proposal: deprecate and remove QEMU's unicore32 target code

[Peter Maydell]

I propose that we deprecate and plan to remove the unicore32 code:

 * It has had no changes since 2012 that were not tree-wide
   maintenance/API changes/other global updates
 * We dropped the linux-user unicore32 support in 2016 because of
   a clash between the 'old ABI' that it was implementing and the
   ABI that's actually in the upstream Linux kernel, and there have
   been no moves to get this fixed so we could re-enable it, nor
   any complaints when it went away
 * Linux is now planning to drop unicore support
   (https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1619640.html)
 * there is apparently no upstream gcc support for the architecture
 * nobody has ever reported a bug or problem to us about it

Essentially, it seems to be a largely-inactive university R&D project,
it's costing us in maintenance effort every time we have to touch it,
and I don't think it has any real users.

Does anybody disagree?

If we go ahead with deprecating then we should:
 * add a note to Changelog that we're deprecating the target
 * ditto qemu-doc.texi's deprecation section
 * patch hw/unicore32/puv3.c to warn on startup that it's deprecated
 * remove it entirely for the 2.14 release

We could also remove linux-user/unicore32 immediately, since
the linux-user target has been disabled for some time.

Possibly there are other target architectures we could reasonably
deprecate-and-remove (though none of the other ones Linux is dropping
in this round are ones we support)...

thanks
-- PMM

Re: [Qemu-devel] Proposal: deprecate and remove QEMU's unicore32 target code

[Daniel P. Berrangé]

On Tue, Feb 27, 2018 at 11:51:13AM +0000, Peter Maydell wrote:
> I propose that we deprecate and plan to remove the unicore32 code:
> 
>  * It has had no changes since 2012 that were not tree-wide
>    maintenance/API changes/other global updates
>  * We dropped the linux-user unicore32 support in 2016 because of
>    a clash between the 'old ABI' that it was implementing and the
>    ABI that's actually in the upstream Linux kernel, and there have
>    been no moves to get this fixed so we could re-enable it, nor
>    any complaints when it went away
>  * Linux is now planning to drop unicore support
>    (https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1619640.html)
>  * there is apparently no upstream gcc support for the architecture
>  * nobody has ever reported a bug or problem to us about it
> 
> Essentially, it seems to be a largely-inactive university R&D project,
> it's costing us in maintenance effort every time we have to touch it,
> and I don't think it has any real users.
> 
> Does anybody disagree?
> 
> If we go ahead with deprecating then we should:
>  * add a note to Changelog that we're deprecating the target
>  * ditto qemu-doc.texi's deprecation section
>  * patch hw/unicore32/puv3.c to warn on startup that it's deprecated
>  * remove it entirely for the 2.14 release

Sounds like a good plan to me.

> We could also remove linux-user/unicore32 immediately, since
> the linux-user target has been disabled for some time.

Agreed.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Qemu-devel] Deprecate tilegx ? (was: Proposal: deprecate and remove QEMU's unicore32 target code)

[Thomas Huth]

On 27.02.2018 12:51, Peter Maydell wrote:
> I propose that we deprecate and plan to remove the unicore32 code:
[...]
> Essentially, it seems to be a largely-inactive university R&D project,
> it's costing us in maintenance effort every time we have to touch it,
> and I don't think it has any real users.
>
> Does anybody disagree?
> 
> If we go ahead with deprecating then we should:
>  * add a note to Changelog that we're deprecating the target
>  * ditto qemu-doc.texi's deprecation section
>  * patch hw/unicore32/puv3.c to warn on startup that it's deprecated
>  * remove it entirely for the 2.14 release
> 
> We could also remove linux-user/unicore32 immediately, since
> the linux-user target has been disabled for some time.

Sounds reasonable to me, but let's wait a week or two for feedback from
Guan Xuetao.

> Possibly there are other target architectures we could reasonably
> deprecate-and-remove (though none of the other ones Linux is dropping
> in this round are ones we support)...

I'd vote for marking tilegx as deprecated, too, since we even do not
have an active maintainer for that CPU core (at least I did not spot one
in our MAINTAINERS file). Opinions?

 Thomas

Re: [Qemu-devel] Deprecate tilegx ?

[Paolo Bonzini]

On 28/02/2018 07:11, Thomas Huth wrote:
> On 27.02.2018 12:51, Peter Maydell wrote:
>> I propose that we deprecate and plan to remove the unicore32 code:
> [...]
>> Essentially, it seems to be a largely-inactive university R&D project,
>> it's costing us in maintenance effort every time we have to touch it,
>> and I don't think it has any real users.
>>
>> Does anybody disagree?
>>
>> If we go ahead with deprecating then we should:
>>  * add a note to Changelog that we're deprecating the target
>>  * ditto qemu-doc.texi's deprecation section
>>  * patch hw/unicore32/puv3.c to warn on startup that it's deprecated
>>  * remove it entirely for the 2.14 release
>>
>> We could also remove linux-user/unicore32 immediately, since
>> the linux-user target has been disabled for some time.
> 
> Sounds reasonable to me, but let's wait a week or two for feedback from
> Guan Xuetao.

Sounds good---thought I would consider dropping unicore32 now with no
formal deprecation period...

>> Possibly there are other target architectures we could reasonably
>> deprecate-and-remove (though none of the other ones Linux is dropping
>> in this round are ones we support)...
> 
> I'd vote for marking tilegx as deprecated, too, since we even do not
> have an active maintainer for that CPU core (at least I did not spot one
> in our MAINTAINERS file). Opinions?

Tilegx has been last modified in 2015, so it's a little more alive than
unicore32.

Another one is moxie.  Anthony?

Thanks,

Paolo

Re: [Qemu-devel] Deprecate tilegx ?

[Thomas Huth]

On 28.02.2018 08:17, Paolo Bonzini wrote:
> On 28/02/2018 07:11, Thomas Huth wrote:
>> On 27.02.2018 12:51, Peter Maydell wrote:
>>> I propose that we deprecate and plan to remove the unicore32 code:
>> [...]
>>> Essentially, it seems to be a largely-inactive university R&D project,
>>> it's costing us in maintenance effort every time we have to touch it,
>>> and I don't think it has any real users.
>>>
>>> Does anybody disagree?
>>>
>>> If we go ahead with deprecating then we should:
>>>  * add a note to Changelog that we're deprecating the target
>>>  * ditto qemu-doc.texi's deprecation section
>>>  * patch hw/unicore32/puv3.c to warn on startup that it's deprecated
>>>  * remove it entirely for the 2.14 release
>>>
>>> We could also remove linux-user/unicore32 immediately, since
>>> the linux-user target has been disabled for some time.
>>
>> Sounds reasonable to me, but let's wait a week or two for feedback from
>> Guan Xuetao.
> 
> Sounds good---thought I would consider dropping unicore32 now with no
> formal deprecation period...
> 
>>> Possibly there are other target architectures we could reasonably
>>> deprecate-and-remove (though none of the other ones Linux is dropping
>>> in this round are ones we support)...
>>
>> I'd vote for marking tilegx as deprecated, too, since we even do not
>> have an active maintainer for that CPU core (at least I did not spot one
>> in our MAINTAINERS file). Opinions?
> 
> Tilegx has been last modified in 2015, so it's a little more alive than
> unicore32.
> 
> Another one is moxie.  Anthony?

For moxie, we've got at least a maintainer in MAINTAINERS, and there is
still a proper project page online
(http://moxielogic.org/blog/pages/architecture.html). And since we've
now also got a mini Moxie TCG test in tests/boot-serial-test.c, the CPU
code is at least still basically working fine. So IMHO there's no urgent
need to mark the moxie CPU as deprecated yet.

 Thomas

Re: [Qemu-devel] Deprecate tilegx ?

[Bastian Koppelmann]

On 02/28/2018 07:11 AM, Thomas Huth wrote:
> On 27.02.2018 12:51, Peter Maydell wrote:
>> I propose that we deprecate and plan to remove the unicore32 code:
> [...]
[...]
> 
> Sounds reasonable to me, but let's wait a week or two for feedback from
> Guan Xuetao.

Agreed.

> 
>> Possibly there are other target architectures we could reasonably
>> deprecate-and-remove (though none of the other ones Linux is dropping
>> in this round are ones we support)...
> 
> I'd vote for marking tilegx as deprecated, too, since we even do not
> have an active maintainer for that CPU core (at least I did not spot one
> in our MAINTAINERS file). Opinions?

I always saw it as a big plus that QEMU supports nearly any
architecture, no matter how obscure it is. So I'm a bit more hesitant on
dropping architectures quickly.

Cheers,
Bastian

Re: [Qemu-devel] Proposal: deprecate and remove QEMU's unicore32 target code

[Xuetao Guan]

> I propose that we deprecate and plan to remove the unicore32 code:
>
>  * It has had no changes since 2012 that were not tree-wide
>    maintenance/API changes/other global updates
>  * We dropped the linux-user unicore32 support in 2016 because of
>    a clash between the 'old ABI' that it was implementing and the
>    ABI that's actually in the upstream Linux kernel, and there have
>    been no moves to get this fixed so we could re-enable it, nor
>    any complaints when it went away
>  * Linux is now planning to drop unicore support
>    (https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1619640.html)
>  * there is apparently no upstream gcc support for the architecture
>  * nobody has ever reported a bug or problem to us about it
>
> Essentially, it seems to be a largely-inactive university R&D project,
> it's costing us in maintenance effort every time we have to touch it,
> and I don't think it has any real users.
>
> Does anybody disagree?
>
> If we go ahead with deprecating then we should:
>  * add a note to Changelog that we're deprecating the target
>  * ditto qemu-doc.texi's deprecation section
>  * patch hw/unicore32/puv3.c to warn on startup that it's deprecated
>  * remove it entirely for the 2.14 release
>
> We could also remove linux-user/unicore32 immediately, since
> the linux-user target has been disabled for some time.
>
> Possibly there are other target architectures we could reasonably
> deprecate-and-remove (though none of the other ones Linux is dropping
> in this round are ones we support)...
>
> thanks
> -- PMM
>

Hi, Peter
I am really sorry to reply so late, since I seldom use this email account
in recent years. I will add my new email account to related bits.

I had sent email to clarify the status of UniCore to Arnd and lkml. In a
word, UniCore is a real product and we still use the port internally. So,
I really appreciate having unicore32 port in the tree.

Thanks,
Guan Xuetao

Re: [Qemu-devel] Deprecate tilegx ?

[Alex Bennée]

Bastian Koppelmann <kbastian@mail.uni-paderborn.de> writes:

> On 02/28/2018 07:11 AM, Thomas Huth wrote:
>> On 27.02.2018 12:51, Peter Maydell wrote:
>>> I propose that we deprecate and plan to remove the unicore32 code:
>> [...]
> [...]
>>
>> Sounds reasonable to me, but let's wait a week or two for feedback from
>> Guan Xuetao.
>
> Agreed.
>
>>
>>> Possibly there are other target architectures we could reasonably
>>> deprecate-and-remove (though none of the other ones Linux is dropping
>>> in this round are ones we support)...
>>
>> I'd vote for marking tilegx as deprecated, too, since we even do not
>> have an active maintainer for that CPU core (at least I did not spot one
>> in our MAINTAINERS file). Opinions?
>
> I always saw it as a big plus that QEMU supports nearly any
> architecture, no matter how obscure it is. So I'm a bit more hesitant on
> dropping architectures quickly.

All things being equal I agree, however there is a maintenance burden
for the QEMU upstream, especially if the only active use if on
out-of-tree branches or behind the closed doors of research groups.

Looking at https://wiki.qemu.org/Documentation/Platforms/TileGX it
doesn't give much of an idea of where I would get toolchains to build
guest binaries or what guest user-space I could run.

--
Alex Bennée

Re: [Qemu-devel] Deprecate tilegx ?

[Chen Gang]

On 2/28/18 20:41, Bastian Koppelmann wrote:
> On 02/28/2018 07:11 AM, Thomas Huth wrote:
>> On 27.02.2018 12:51, Peter Maydell wrote:
>>
>>> Possibly there are other target architectures we could reasonably
>>> deprecate-and-remove (though none of the other ones Linux is dropping
>>> in this round are ones we support)...
>>
>> I'd vote for marking tilegx as deprecated, too, since we even do not
>> have an active maintainer for that CPU core (at least I did not spot one
>> in our MAINTAINERS file). Opinions?
> 
> I always saw it as a big plus that QEMU supports nearly any
> architecture, no matter how obscure it is. So I'm a bit more hesitant on
> dropping architectures quickly.
> 

Firstly, sorry for too long time to no response about tilegx.

During latest 2 years, I turned to android development (custom aosp with
java/c++/c, merge android and linux together), and revert engineering
about android (java/c).

At present, sorry, I really have no time for tilegx any more. :(

For me, tilegx is still a good platform, and we have done much things,
now, so if we can find another maintainers/volunteers for it, I hope
qemu can still support tilegx.

By the way, for floating point instructions patches, I have sent before
(2 years ago), it seems I did not get any reply. I hope they are useful
for tilegx.

Thanks.
-- 
Chen Gang (陈刚)

Re: [Qemu-devel] Deprecate tilegx ?

[Bastian Koppelmann]

On 03/09/2018 04:13 PM, Alex Bennée wrote:
> Bastian Koppelmann <kbastian@mail.uni-paderborn.de> writes:
[...]
>> I always saw it as a big plus that QEMU supports nearly any
>> architecture, no matter how obscure it is. So I'm a bit more hesitant on
>> dropping architectures quickly.
> All things being equal I agree, however there is a maintenance burden
> for the QEMU upstream, especially if the only active use if on
> out-of-tree branches or behind the closed doors of research groups.
>
> Looking at https://wiki.qemu.org/Documentation/Platforms/TileGX it
> doesn't give much of an idea of where I would get toolchains to build
> guest binaries or what guest user-space I could run.

I'm not saying, we shouldn't drop them. To me it felt like we brought 
just another target to the chop block while we were at it.

Maybe a good approach is to deprecate the target first, then ask if 
somebody else is willing to maintain it, and if this fails, drop it.

Cheers,
Bastian

Re: [Qemu-devel] Deprecate tilegx ?

[Peter Maydell]

On 13 March 2018 at 17:18, Bastian Koppelmann
<kbastian@mail.uni-paderborn.de> wrote:
> On 03/09/2018 04:13 PM, Alex Bennée wrote:
>>
>> Bastian Koppelmann <kbastian@mail.uni-paderborn.de> writes:
>
> [...]
>>>
>>> I always saw it as a big plus that QEMU supports nearly any
>>> architecture, no matter how obscure it is. So I'm a bit more hesitant on
>>> dropping architectures quickly.
>>
>> All things being equal I agree, however there is a maintenance burden
>> for the QEMU upstream, especially if the only active use if on
>> out-of-tree branches or behind the closed doors of research groups.
>>
>> Looking at https://wiki.qemu.org/Documentation/Platforms/TileGX it
>> doesn't give much of an idea of where I would get toolchains to build
>> guest binaries or what guest user-space I could run.
>
>
> I'm not saying, we shouldn't drop them. To me it felt like we brought just
> another target to the chop block while we were at it.
>
> Maybe a good approach is to deprecate the target first, then ask if somebody
> else is willing to maintain it, and if this fails, drop it.

Personally, I think it's useful to consider not merely "do we
have anybody actively maintaining this" (after all our x86 frontend
is not exactly very well-loved!) but also "are there users of QEMU
out there using it?" and "is this actually something that exists
in the real world as actual silicon in any quantity?". I think
unicore32 failed on both of those, but tilegx passes the latter
and possibly the former.

thanks
-- PMM

Re: [Qemu-devel] Deprecate tilegx ?

[Xuetao Guan]

> [...]
> Personally, I think it's useful to consider not merely "do we
> have anybody actively maintaining this" (after all our x86 frontend
> is not exactly very well-loved!) but also "are there users of QEMU
> out there using it?" and "is this actually something that exists
> in the real world as actual silicon in any quantity?". I think
> unicore32 failed on both of those, but tilegx passes the latter
> and possibly the former.
>
> thanks
> -- PMM
>

UniCore is a real silicon product, integrated into PKUnity SoC, and sold
in a large amount of embedded boxes, such as cloud terminals and set top
boxes. Since we provide complete product solutions, few users use QEmu
directly to simulate the booting and running of unicore32-linux runtime
system.
For me, I still maintain unicore32 port, and I really appreciate having
unicore32 port in the tree.

Thanks

Guan Xuetao

Re: [Qemu-devel] Deprecate tilegx ?

[Laurent Vivier]

Le 14/03/2018 à 10:09, Xuetao Guan a écrit :
> 
>> [...]
>> Personally, I think it's useful to consider not merely "do we
>> have anybody actively maintaining this" (after all our x86 frontend
>> is not exactly very well-loved!) but also "are there users of QEMU
>> out there using it?" and "is this actually something that exists
>> in the real world as actual silicon in any quantity?". I think
>> unicore32 failed on both of those, but tilegx passes the latter
>> and possibly the former.
>>
>> thanks
>> -- PMM
>>
> 
> UniCore is a real silicon product, integrated into PKUnity SoC, and sold
> in a large amount of embedded boxes, such as cloud terminals and set top
> boxes. Since we provide complete product solutions, few users use QEmu
> directly to simulate the booting and running of unicore32-linux runtime
> system.
> For me, I still maintain unicore32 port, and I really appreciate having
> unicore32 port in the tree.

We keep unicore32 in the system emulation part, but my latest pull
request removes it from the linux user emulation part (patch from Peter
Maydell) as it is broken and disabled for a long time now.

If you want unicore32 in the linux-user emulation part, you must fix it
and send a patch series to re-introduce it.

Moreover, in the future, to be able to test it, I'd like to know where
to find a distro I can install.

Thanks,
Laurent

Re: [Qemu-devel] Deprecate tilegx ?

[Xuetao Guan]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain;charset=gb2312, Size: 1782 bytes --]

> Le 14/03/2018 à 10:09, Xuetao Guan a écrit :
>>
>>> [...]
>>> Personally, I think it's useful to consider not merely "do we
>>> have anybody actively maintaining this" (after all our x86 frontend
>>> is not exactly very well-loved!) but also "are there users of QEMU
>>> out there using it?" and "is this actually something that exists
>>> in the real world as actual silicon in any quantity?". I think
>>> unicore32 failed on both of those, but tilegx passes the latter
>>> and possibly the former.
>>>
>>> thanks
>>> -- PMM
>>>
>>
>> UniCore is a real silicon product, integrated into PKUnity SoC, and sold
>> in a large amount of embedded boxes, such as cloud terminals and set top
>> boxes. Since we provide complete product solutions, few users use QEmu
>> directly to simulate the booting and running of unicore32-linux runtime
>> system.
>> For me, I still maintain unicore32 port, and I really appreciate having
>> unicore32 port in the tree.
>
> We keep unicore32 in the system emulation part, but my latest pull
> request removes it from the linux user emulation part (patch from Peter
> Maydell) as it is broken and disabled for a long time now.
>
> If you want unicore32 in the linux-user emulation part, you must fix it
> and send a patch series to re-introduce it.

For unicore32-linux-user part, that's ok to remove it. We haven't updated
it since abi changed. Thanks Laurent. It should be my work.

>
> Moreover, in the future, to be able to test it, I'd like to know where
> to find a distro I can install.
>
> Thanks,
> Laurent
>
After both qemu and linux update to latest version, I'll put a busybox
system on my website for test. Maybe four months later, since my time is
limited recently.

Thanks,
Guan Xuetao

Re: [Qemu-devel] Deprecate tilegx ?

[Waldemar Brodkorb]

Hi,

> Am 09.03.2018 um 16:13 schrieb Alex Bennée <alex.bennee@linaro.org>:
> 
> 
> Bastian Koppelmann <kbastian@mail.uni-paderborn.de> writes:
> 
>>> On 02/28/2018 07:11 AM, Thomas Huth wrote:
>>>> On 27.02.2018 12:51, Peter Maydell wrote:
>>>> I propose that we deprecate and plan to remove the unicore32 code:
>>> [...]
>> [...]
>>> 
>>> Sounds reasonable to me, but let's wait a week or two for feedback from
>>> Guan Xuetao.
>> 
>> Agreed.
>> 
>>> 
>>>> Possibly there are other target architectures we could reasonably
>>>> deprecate-and-remove (though none of the other ones Linux is dropping
>>>> in this round are ones we support)...
>>> 
>>> I'd vote for marking tilegx as deprecated, too, since we even do not
>>> have an active maintainer for that CPU core (at least I did not spot one
>>> in our MAINTAINERS file). Opinions?
>> 
>> I always saw it as a big plus that QEMU supports nearly any
>> architecture, no matter how obscure it is. So I'm a bit more hesitant on
>> dropping architectures quickly.
> 
> All things being equal I agree, however there is a maintenance burden
> for the QEMU upstream, especially if the only active use if on
> out-of-tree branches or behind the closed doors of research groups.
> 
> Looking at https://wiki.qemu.org/Documentation/Platforms/TileGX it
> doesn't give much of an idea of where I would get toolchains to build
> guest binaries or what guest user-space I could run.

Just from a user perspective, I like the different architecture support qemu provides. I use it often for regression testing of uClibc-ng.
Regarding tilegx I used qemu to start with the port of tilegx from glibc to uClibc-ng and it worked well for the binaries produced by OpenADK.

best regards
 Waldemar