[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Deprecate lm32 port
From: |
Thomas Huth |
Subject: |
Re: [PATCH] Deprecate lm32 port |
Date: |
Thu, 27 Aug 2020 16:50:25 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 |
On 27/08/2020 16.19, Peter Maydell wrote:
> On Thu, 27 Aug 2020 at 14:52, Thomas Huth <thuth@redhat.com> wrote:
>> What's next? moxie? ... apart from the tree-wide clean-ups and trivial
>> fixes, moxie did not have any major updates since 2013 when it has been
>> added, as far as I can see ... is anybody still using it?
>
> I was never very clear on how much use moxie had to start with...
>
> An extremely rough-and-ready guide to how well-loved a target
> is might be "did it get converted to TranslatorOps?". Unconverted:
> * avr
> * cris
> * lm32 (deprecation in progress)
> * microblaze (rth just posted patches for this)
> * moxie
> * nios2
> * tilegx (deprecation in progress)
> * unicore32 (deprecation in progress)
Another criteria might be: Do we have a tcg, qtest or acceptance test to
check that the target is still working?
- avr has an acceptance test
- cris has tcg tests
- lm32 has tcg tests
- microblaze has acceptance tests (and one trivial qtest)
- moxie ... has only one very trivial qtest (boot-serial-test)
- nios2 has an acceptance test
- tilegx does not have any tests at all
- unicore32 does not have any tests at all
(not counting the trivial machine-none-test)
So from that point of view, unicore32, tilegx and moxie are the
candidates for deprecation.
> I think dropping the moxie maintainer an email to ask about
> the architecture's status wouldn't be a bad idea if you
> wanted to start that ball rolling.
Ok, good idea, I'll try to write a mail later today.
Thomas