In message <5962aaafabSpambin@argonet.co.uk> you wrote:
> In article <59628c2362Spambin@argonet.co.uk>,
> Stuart <Spambin@argonet.co.uk> wrote:
>> In article <20210827110113.GN31179@chiark.greenend.org.uk>,
>> Theo Markettos <theo@markettos.org.uk> wrote:
>>> Agreed, but the 'virt' platform would require the timer modernisation
>>> above. I'd suggest it's better to invest in that kind of modernisation
>>> rather the improving a specific implementation of a specific emulator.
>> So perhaps it would be better if David Feugey invested his time and money
>> on something useful like this rather than going off at a tangent and
>> "doing his own thing"
> dfeugey@ascinfo.fr
> Wrote:
> I have the sensation not to be the owner of my time and my money any more.
> Did I force you to adopt my own view?
Stuart, that's very kind of you to post here a private message.
FYI, GDPR exists also in UK. See ICO website.
Thanks!
Anyway, I was certainly wrong to feed the anger where it's not really your
fault after all. Sorry for that. I'm just a bit fed up repeating myself
every time some accuses me of things I did not say (I suspect there is
some confusion with someone else messages and/or a PM organized flamewar).
Just in case someone did not yet see my previous messages:
1/ Native RISC OS Linux port using QEMU for hardware layer already exists:
it's RISC OS on Linux (made by Timothy Baldwin). Nota: perhaps some ideas
can be taken here for point 2. But it's off topic on a RPCEmu mailing
list.
2/ A way to make RISC OS working under QEMU as a full VM would be cool. As
I told earlier, I like the idea. In fact, one in France made a QEMU patch
a few years ago for RISC OS support. The patch did not raise any interest
on the QEMU side. I think it's normal: the problem would be better be
solved on the RISC OS side. Nota: the RPCEmu ARM emulation was much faster
than the QEMU one at this time (and is perhaps still). All of this is also
off topic on a RPCEmu mailing list.
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 said in my first message I
like this idea, and if someone wants to make the job, I could even pay
some money for this (not all, as it's a personal wish). I will also
support work for a better RPCEmu RISC OS port. That's all.
I did not force anyone to do this. I did not suggest to put ARMv7 support
in RPCEmu. I did not suggest that RPCemu should be suitable to modern uses
(even if it is, for me and my clients, but that's another story). And I
did not suggest to fork the project or to destroy the spirit of RPCEmu.
And I'm from the embedded electronics industry, ex CTO of a company proved
to be a leader in the Linux embbeded market a few decades ago. But, all of
you (I hope) perfectly know an argument of authority as 0 value.
Sorry for my very bad english. I promise I will soon go back to my
previous position of silent-reader. With all this drama, I'll remember the
lesson: it's better not to talk :)
David
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
No comments:
Post a Comment