>On Wed, Aug 25, 2021 at 02:38:16PM +0000, Sarah wrote:
>> On Wednesday, 25 August 2021, 14:20:47 BST, Theo Markettos <theo@markettos.org.uk> wrote:
>>
>> >RISC OS currently uses some undocumented firmware interfaces
>>
>> Please tell me this is a joke. That code needs to come out ASAP, and
>> should never have been checked in.
>
>It's not a joke, it's because the RISC OS port and the firmware have
>co-evolved. Originally there were no documented firmware interfaces,
>because there was no documentation - there were simply emails to the
>firmware developers. Later on some bits got documented, but it turned out
>not the ones RISC OS implemented.
Well once it became clear that some of the interfaces RO was using were not going to be documented, they should have been stripped out of the codebase; that's a pretty obvious sign that there are no guarantees that those interfaces are going to stay in the FW.
>(This is how a lot of stuff gets developed,
I do work in the industry, there's no need to patronise me. I am aware this is practice, however it also happens to be _bad_ practice.
>The firmware is loaded before the OS boots, so you don't get to control what
>firmware you're running on.
Even more reason to remove the undocumented interface usage from RO. Because you have no guarantees that those interfaces aren't going to change or just simply go away.
>Changing RISC OS to use the documented interface for USB power control,
>which is the one I found, is a small change. The timer issue is a more
>substantial roadblock, and that's a hard peripheral that QEMU doesn't
>implement because other OSes use the ARM's own timer instead.
So why is RO different to everyone else?
>But I raise this as more of a philosophical point: modern systems are
>complex and change over time - they are not fixed at a point in the past
>like older hardware was.
They _are_ effectively fixed if you stick to the public documented interfaces. No SoC vendor who wants to stay in business is going to wildly change the public FW interfaces on a whim, so those can be considered reasonably stable. The same can _not_ be said for the undocumented interfaces, which is why RO using them effectively leaves the OS sitting on a timebomb.
>Particularly when you can bend both sides to meet each other, it's then a
>question of which side is easier to bend, and which incurs you the least costs.
Bending your side to meet the quirks of a current inaccurate implementation of something else leaves you screwed if said other side becomes more accurate. Which is quite likely to happen; QEMU is aiming to emulate a Pi, not "something like a Pi", and they are quite likely to make changes to bring their emulation closer to a real Pi. At which point RO has _more_ costs having to readjust.
If you just want something for virtualisation that doesn't want to look like a Pi, QEMU has the 'virt' platform for that, and there's no reason RO couldn't port to that. Porting specifically to "the current state of the Pi emulation" rather than fixing the problematic elements of said Pi emulation is just asking for trouble.
Sarah
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
No comments:
Post a Comment