On 02/07/14 08:36, Andres Freund wrote:
> On 2014-07-01 20:21:37 -0400, Tom Lane wrote:
>> Andres Freund <andres@2ndquadrant.com> writes:
>>> On 2014-07-01 23:21:07 +0100, Mark Cave-Ayland wrote:
>>>> Also if you're struggling for Sun buildfarm animals, recent versions of QEMU
>>>> will quite happily install and run later versions of 32-bit Solaris over
>>>> serial, and 2.0 even manages to give you a cgthree framebuffer for the full
>>>> experience.
>>
>>> Well. I have to admit I'm really not interested in investing that much
>>> time in something I've no stake in. If postgres developers have to put
>>> emulated machines to develop features something imo went seriously
>>> wrong. That's more effort than at least I'm willing to spend.
>>
>> Perhaps more to the point, I have no faith at all that an emulator will
>> mimic multiprocessor timing behavior to the level of detail needed to
>> tell whether memory-barrier-related logic works. See the VAX discussion
>> just a couple days ago.
>
> Well, it would allow us to see wether fixed stuff actually compiles and
> runs - that's not nothing. The biggest problem with fixing stuff like
> armv5, sparc8, whatever is that it requires adding stuff to our inline
> assembly. It's easy to accidentally make it not compile, but
> comparatively harder to make the behaviour even worse than before.
The point I wanted to make was that there are certain applications for
which SPARCv8 is still certified for particular military/aerospace use.
While I don't use it myself, some people are still using it enough to
want to contribute QEMU patches.
In terms of QEMU, the main reason for mentioning it was that if the
consensus were to keep SPARCv8 support then this could be one possible
way to provide basic buildfarm support (although as Tom rightly points
out, there would need to be testing to build up confidence that the
emulator does the right thing in a multiprocessor environment).
ATB,
Mark.