Have a look at this post in particular, and threads like this and this in general, and you will see that:
1) Full Amiga legacy compatibility is *impossible* to begin with
2) and *on top of that* there are lots of hurdles to overcome and performance penalties to pay, if you *persist* in going this way despite the fact that you have already broken compatibility and a rebuild of the SW base will be required anyway (hence an opportunity to introduce a SMP model that is more *real world tried* and less "silly").
I *have* followed Jason's work, and you are massively overdramatising this.
It is fully possible to make AmigaOS SMP with *no* source changes. This is not the problem. The problem is making AmigaOS SMP in a way that scales efficiently to many cores. The "trivial" way of making AmigaOS fully SMP is to memory protect all shared structures, make Forbid() etc. work across all cores, and brutally enforce cache coherency - do that and you can create a system that is *provably* equivalent to a multi-tasking single-CPU system, in that you can in fact guarantee no *observable* differences to processes.
(In fact, you can further relax the above by using well researched approaches from database theory: By using the MMU to trigger page faults and pause processes that try to touch the same pages as the process that called Forbid(), you can create the *effect* of a system wide Forbid() while allowing processes that don't touch the "wrong" parts of the system to keep running)
The question then is what tradeoffs you need to make to get decent scalability across cores, and SillySMP has started to determine that.
For AROS this issue is massively simplified in that:
1) AFAIK there are nobody crazy enough to plan to try to build an m68k SMP machine to run AROS. As such "our" m68k apps are limited to running in UAE, possibly in coherence mode, which means that while the applications themselves may be "badly behaved" they have no direct access to AROS system structures - all access is mediated.
2) All other applications are compiled for AROS anyway.
"Amiga legacy" compatibility is thus "easy" for AROS: Make the UAE process handle SMP, for values of "handle SMP" that can worst case involve making the UAE processes only run on a single CPU and aggressively apply locking (though there is little reason why this needs to be the case).
A substantial percentage of applications compiled for AROS will require no source changes: Many of them never touch system structures in a way that will prove problematic even in an "optimal" SMP implementation. Many more can handle things fine with the approach that SillySMP takes.
For the ones that *do* need changes, most or all of those changes can be made in a way that is backwards compatible to plain AmigaOS (that is, we can write SMP safe applications in a way that we can ensure will continue to work if recompiled for non-SMP AmigaOS): We simply need more fine-grained locking, which can be provided in a way that'll either work on AmigaOS (but that would require you only run well behaved apps) or fall back on Forbid() on AmigaOS.
And in fact, as Jason pointed out in a couple of comments on the threads you pointed to, some of the "problematic" behaviour is *broken* on AmigaOS anyway, and just happens to "mostly work" by sheer luck. In fact, this may prove to be the biggest challenge.
No, no, no, either it's 100% compatible, or it's NOT! There is *nothing* in between! It's purely digital, either 1 or 0, it's either fully black or fully white.
I nominate this as the most ridiculous statement of the decade. Did you ever have a kickstart 1.2 machine and upgrade to 1.3? 2.0? 3.1? Each of those were an example of a "not 100% compatible" upgrade. Yet I'd expect few people here would argue they were not mostly compatible.
Purposely building an OS that sits in the grey scale between black and white will mean that its applications will be running in a mine field; Some may perhaps run, some longer than others, but there are no guarantees whatsoever. This is simply not serious, it would be a joke, and any OS developer who thinks that "less than 100% compatibility/stability" is OK and actually something to *aim for*, shouldn't be taken seriously as well!
You completely miss the point. The point is not that it is acceptable to run applications that randomly break, but that it is completely acceptable to say "ok, this will work fine for about 90% of applications, the rest *either must be sandboxed, must be fixed, or you can't run them*". The idea of 100% compatibility is a unicorn - it's a fantasy. And it's better to give up on the idea, and be pragmatic about it:
Our application base is small enough that for many types of changes, it is less effort to *test and verify* and *fix* or accept that some apps will not be usable outside of UAE than it is to obsess over a 100% compatibility that will forever hamper us. AROS is not identical to AmigaOS anyway: We *need* to test and verify every application on a regular basis to ensure that changes does not break apps that works fine on AmigaOS. And the same will be true for ARIX.
Every iteration of the actual AmigaOS left applications behind that were broken, and/or forced people to upgrade their applications for them to keep working too - this is nothing new. What is new is that for the NG OS's we have sandboxing as an "easy" alternative to keep those applications running if the effort to fix them is too great.
