Moving AUX_CHANNELS, NUM_CHANNELS logic into platform hal

[Gary Thomas]

David Fernandez wrote:
> On Sat, 2006-11-25 at 16:14 -0700, Gary Thomas wrote:
>   
>> David Fernandez wrote:
>>     
>>> Hi there,
>>>
>>> This patch moves a conflicting logic to define
>>> CYGNUM_HAL_VIRTUAL_VECTOR_NUM_CHANNELS, that was being defined in
>>> redboot.h and in hal_if.c; to the platform hal, and implemented in a
>>> more general way, that allows more modules to increase the number of
>>> channels.
>>>       
>> Can you explain the purpose of this change more fully?  e.g. how does
>> it differ than just expanding on CYGNUM_HAL_VIRTUAL_VECTOR_COMM_CHANNELS
>> within the platform HAL (the way it's been done on a number of HALs)?
>>
>>     
> The purpose is to replace the #define
> CYGNUM_VIRTUAL_VECTOR_NUM_CHANNELS, the problem is that the NUM_CHANNELS
> define was in two places (hal_if.c and redboot.h), which causes a
> warning in hal_if.c itself; besides, it seems more appropriate to put
> that definition in the platform hal cdl, like COMM_CHANNELS is, making
> it a hal wide macro, and not a local define here and there.
>   

On what platform?  Not on any one I'm responsible for!
> At the moment I've only seen that NUM_CHANNELS macro to be used by
> RedBoot when enabling networking in it; but that other way, it could be
> used by other modules that could benefit from the same mechanism present
> in hal_if.c (hal/common).
>
> Instead of making the RedBoot networking option to do a "puts" with the
> AUX_CHANNELS macro, it does now a "implements" command on AUX_CHANNELS,
> that becomes a interface; then NUM_CHANNELS becomes an option that
> augments COMM_CHANNELS with a "calculated" value. Is the same thing done
> in the #defines in redboot.h and hal_if.c, but it seems more general and
> less redundant.
>
>   
I understand the mechanics - I still don't see how this changes 
anything.  Do you have a platform that
needs more "AUX" channels?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------