Yay, I’ve killed all nightly builds. Sorry 😉
That was the short version. Last weekend I was busy with removing some legal hacks from AROS sources. The hack on the schedule was commonly used ThisTask pointer in the SysBase. Now, at least in my local branch of AROS for RaspberryPi the SysBase->ThisTask points to a nirvana place where all code is either happy crashing, or dead, or both. ThisTask points to NULL
No, it didn’t disappeared completely. The ThisTask pointer has been moved (and is used there) to something similar to a thread local storage. It is local, but not local for a thread. It is local to a CPU core. On RPi2 we use four independent local storages and each of them has it’s own ThisTask pointer. Don’t hold your breath, it’s not SMP yet. Far from it The scheduler works only on the CPU#0. At least for now.
The TLS is used exclusively by the kernel.resource, which knows best about the low-level part of the system. Exec has become two new architecture-specific macros, named GET_THIS_TASK and SET_THIS_TASK(x). On all architectures they do expand to SysBase->ThisTask, on RaspberryPi they expand to TLS_GET(ThisTask) and equivalent TLS_SET. What about the rest of the AROS code? Well, in that case the only sane way to get ThisTask shall be used — the FindTask(NULL) call.
And here we come to the point where I’ve killed all nightlies. During my ThisTask removal fun I broke accidentally one macro in AROSTCP network stack It should be fixed already.