On Friday, 27 August 2021, 20:54:39 BST, David Feugey <dfeugey@ascinfo.fr> wrote:
>3/ Back to topic - IMHO, QEMU will never have integration features as
>hostfs. This project is not made for this, at all. RPCemu does have some
>(hostfs, mouse integration, transparent networking). So I did suggest we
>could have more: printer integration, working 'reduced cpu mode', better
>memory map or graphics... or perhaps simply a way (api, example, tools) to
>make our own integrations (as in VirtualRPC). And if some integrations
>proved to be difficult to support under RISC OS 4 guests, I'm not against
>to see them supporting only RISC OS 5 guests.
I think the fundamental problem we've had here, is that your requests don't really make a lot of sense. From my perspective, as a former developer of both RPCemu and RISC OS 5, the most useful change that could be made to aid with RO5 integration is implementing ARMv7; as far as I can tell, lack of ARMv7 support in RPCemu is holding back adoption of more recent architecture features in both the OS and application software, as RPCemu is still the main virtualisation solution for RO5. Dropping older architecture versions in RO would also simplify some areas of the kernel, removing the need for fallback paths only used by obsolete CPUs and easing maintenance.
However, in the very first post in this thread, Peter Howkins detailed why RPCemu would not be adding ARMv7 support, for reasons I fully agree with. Hence to me the far more sensible route to improve RO5 virtualisation is to move to a more suitable emulator; namely QEMU. Theo has very helpfully clarified the situation with RO5 vs QEMU's Pi emulation, which had previously been somewhat garbled; if RO5 moves away from using undocumented firmware interfaces then it should be feasible to use QEMU for virtualisation, emulating what is now the most common hardware platform for RO, with numerous benefits over RPCemu. There is a question over host integration features like HostFS, but in the worst case an RO integrated fork of QEMU could be created for this. If the Pi emulation proves to be inadequate then QEMU's "virt" platform would be more suitable, and provides more options for integration with eg graphics acceleration, though this would require some additional porting work on the RO side.
You seem to have completely ruled this out though, claiming you don't want ARMv7 support, but provide a list of other features. Without ARMv7 support in the primary virtualisation solution both the OS and most of the software will be held back by being forced to keep compatibility with a more than 25 year old platform. This would either split the userbase (which I'm sure most people would agree has happened quite enough already) leaving people running on virtualisation as second class citizens unable to run newer software, or it results in a situation where no-one will use any of the newer instructions, wasting a lot of potential in the modern hardware platforms. This would include rendering VFPSupport irrelevant, a project you were keen to tell me you worked on.
In addition, while I don't want to put words into the Howkins' mouths, the impression I get from them is that little to none of the work you propose would stand much of a chance of being accepted into RPCemu mainline. Therefore you would have to create and maintain a fork of RPCemu, which would (again) split the userbase and create a lot of bad feelings. You would have ended up spending a good deal of money (I did give you an estimate of what I thought this was likely to cost...) and developer time, with the result of damaging both RO5 and RPCemu for little real benefit.
So, again, why do you want this?
Sarah
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
No comments:
Post a Comment