SMP Patches

[Gedare Bloom]

Hi Marta,

This is great! I will try to set aside time to review the PRs and give
some detailed comments.

I do have a few concerns that you might be able to address pre-emptively:
* Naming: score naming convention pattern is _Package_Method so in C++
package::method(), with only the first letter of the Method name to be
capitalized. Some of the new functions being added by these patches do
not follow the naming convention.

* API explosion: It isn't clear to me what the right way to extend the
existing API functions should be. The approach taken so far has been
to implement new functions that are called only when the SMP is
configured, so that uniprocessor RTEMS is unaffected by SMP code. I
glanced at the thread initialization patch (PR 1806) and it adds a new
function that is wrapped by the existing _Thread_Initialize(...),
which adds a function call to the uniprocessor RTEMS. This is
initialization so not a big deal, but a better pattern would be to
separately initialize the SMP-related thread metadata, for example in
cpukit/rtems/src/taskcreate.c:
 status = _Thread_Initialize(...);
 ...
 #if defined(RTEMS_SMP)
   status = _SMP_Thread_initialize(...);
 #endif
or something similar.

I will give detailed feedback on each PR when I can get to them.
Thanks,
Gedare

On Tue, May 24, 2011 at 11:17 AM, Marta Rybczynska
<marta.rybczynska at kalray.eu> wrote:
> Hello all,
> We're doing SMPization of RTEMS for use with a platform not yet merged with
> RTEMS upstream. We've decided contribute the effort so the same work is not
> done twice and started recently to submit patches.
>
> The current list is:
> 1803 _Thread_Is_executing and _Thread_Is_heir
> 1806 SMP: affinity step #1
> 1808 PerCore SMP Scheduler
> 1809 SMP : Lock/Unlock critical Section
>
> Internally, we have a (mostly) working SMP configuration, with applications
> using RTEMS or POSIX API.
>
> The next set of patches will include:
> * Extensions to the message passing/handling interface
> * Big_Kernel_Lock used in _Lock_Critical_Section/_Unlock_Critical_Section
> * impure_ptr/struct reent handling in newlib/RTEMS
> * Timer handling
> * Affinity: IDLE threads
> * Affinity: RTEMS API
> * Affinity: POSIX API
> * Numerous locking fixes/updates/changes
>
> We have also some not-really-SMP-related fixes. In general, you can expect a
> flood of PRs from the kalray.eu domain. Discussion, of course, welcome.
>
> Regards,
> Marta Rybczynska
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>