[Bug 1946] Asymmetric SMP mega-patch

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1946

--- Comment #3 from Frederic Brault <frederic.brault at kalray.eu> 2011-10-27 04:58:44 CDT ---
(In reply to comment #2)
> Some preliminary remarks based on "first time" visual inspection of the patch:
> 
> - There are undefined references to something called "k1" 
>   (grep for __k1_recursive inside of this patch)
>   Seems to me, as if this patch was developed for a proprietary "k1"
>   target/cpu,  contains k1-specific parts and lacks general parts.
> 
> - There is a large number of patches, which
>   append _Lock_Critical_Section to  _ISR_Disable
>   rsp.
>   prepend _Unlock_Critical_Secition to _ISR_Enable
>   while there is a small number of which don't.
> 
>   "this looks unlogic" to me and at least needs to be examined 
>   in detail and to be explained.

 - The architecture on which we are running in AMP configuration is indeed
called k1. Of course, we will remove all references to it. One reason why we
have such specific parts is that our low-level lock instructions did not fit
the SMP_CPU_SWAP macro and general RTEMS lock mechanism, which made too many
assumptions (32 bit lock value, for example). We will clean that up.

- There is indeed an issue with ISR_Disable and Lock_Critical_Section. Please
see my PR Bug 1809. Basically, the issue is that most of the time,
ISR_Disable/Enable is used to protect a critical section, which needs locking
in the case of SMP. But there is a limited number of files where ISR_Disable is
there just to disable ISR, and a lock is unnecessary. more info in PR 1809.


Bottom line : we are very well aware that there is a lot of work to do to clean
up and split this huge patch.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.