Multilib swamp

Till Straumann strauman at slac.stanford.edu
Wed Mar 2 17:50:43 UTC 2005



Ralf Corsepius wrote:

>On Wed, 2005-03-02 at 06:36 -0600, Joel Sherrill  wrote:
>
>  
>
>>I know TIll and I are being non-committal here but the perfect decision
>>varies based upon the code in question, when it is executed. and when it 
>>can vary.  Untested or untestable code is obviously bad.  Creating
>>multilib variants is even worse.  Given that this is an initialization
>>issue, I would lean to dynamic checking -- this code ends up under
>>libbsp anyway.
>>    
>>
>You don't need dynamic checking, if the code "ends up under libbsp". You
>can add the code to libcpu or to the bsp in both cases and add
>appropriate defines to bspopts.h or to CFLAGS to conditionally enable
>it.
>
>If you feel you need to use the code under cpukit, add appropriate
>definitions ("extern functions" -- API!) to cpukit and implement these
>functions into libcpu or the BSP.
>
>The rule of thumb is: You must not add defines to cpukit/score, unless
>inevitable.
>  
>
Brings me right back to the question I asked originally - how could we 
best add hooks for
altivec register context switching [ without introducing an ugly #ifdef 
__PPC__ into cpukit]?

Ideas?

T.

>Ralf
>
>
>  
>





More information about the users mailing list