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