> 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
