The "S" and "I" functions would no more be sufficient, we would need to split those in "SG"/"IG" (global lock required) and "SL"/IL" (local lock sufficient), and the lock functions would become chSysGobalLock()/Unlock() and chSysLocalLock()/Unlock(), this would break compatibility for some APIs.
So (if I understand well) the current chSysLock()/Unlock() would become the alias of chSysGlobalLock()/Unlock() functionality.
Depending on the current Port mode the API of "ChSys" locking would be...
1. Unicore mode - effectively just disable/enable IRQ
2. Multi-core non SMP - same as unicore just with two separate instances of OS running (issue with common peripheral use?)
3. Multi-core SMP - implements spinlock for chSysLock()/Unlock() and adds chSysLocalLock()/Unlock() (which just disables/enable IRQ)
Currently we have one registry for each core, threads can only enumerate threads belonging to the same core. It would be nice to have a single registry able to enumerate all threads.
Agreed.
Using named lookup for instances would need to lock in the naming conventions. i.e. "ch" for core 0, "ch1" for core 1, "ch2" for core 2, etc.
Then think about thread registry which has backward compatibility... i.e. an instance named thread designation e.g. "ch:main" (or some other form of designation) TBD to allow threads to be referenced by affinity (or "any" if a specific instance is not specified).
It is already possible to associate threads to specific cores, it would be nice to be able to allocate working areas in "preferred" RAMs belonging to the various cores for performance optimization.
Agreed. Allowing threads to migrate cores (as per the Common Ready Queue topic) makes sense.
This leads to other discussion about load sharing, stopping cores, etc. (rather out of scope ATM).
Anyway also to be considered is the MAKE and .ld system. i.e. Main stack and exception stack for other cores should be described in MAKE?...
USE_PROCESS_STACKSIZE_C1
USE_EXCEPTIONS_STACKSIZE_C1
The question is: should we release the current implementation or wait to implement all the possible enhancements? this could mean months of delays. Note that 20.x is very good and there is no need to rush IMHO.
Seems the muti-core/SMP port is very close to "good enough".
The addition of multi-core registry stuff to RT is wise to do ATM.
Then the RP2040 device peripheral set would need to be extended to allow applications to be implemented.
Minimal set would be to add SERIAL wrapper to SIO, add I2C and SPI and perhaps that should then be enough to enable some "real world" testing.
A priority list order thereafter might be USB, QSPI, WDG and then some fun stuff (PIO).
--
Bob