Hi, > Am 09.03.2018 um 16:13 schrieb Alex Bennée <alex.ben...@linaro.org>: > > > Bastian Koppelmann <kbast...@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
