Re: [ECOS] vrc437x virtual vector support

[Jesper Skov <jskov at redhat dot com>]

>>>>> "Jonathan" == Jonathan Larmour <jlarmour@redhat.com> writes:

>> 2) In plf_serial.c, I guess that cyg_hal_plf_serial_xxx functions
>> should be enbraced by #ifndef
>> CYGSEM_HAL_VIRTUAL_VECTOR_INHERIT_CONSOLE or #if
>> CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_COMMS rather than #ifdef
>> CYGSEM_HAL_VIRTUAL_VECTOR_SUPPORT according to the original meaning
>> that applications use the ROM monitors resources. In other words,
>> is it necessary that applications include the code of these
>> functions?

Most other platforms that are VV enabled do the table initialization
unconditionally. The decision of whether to call the _init() function
is made in hal_if.c (according to CLAIM_COMMS).

The vrc4373 code looks different because it predates the VV magic and
retains (configurably) the old behavior (i.e., non-vectored calls to
the IO functions).   Actually, I think (if anything) it should be
conditional on CYGINT_HAL_VIRTUAL_VECTOR_SUPPORT_NOT_GUARANTEED which
is the piece of magic intended to help platform HALs move from the old
world to the new one. 

However, seeing as CYGSEM_HAL_VIRTUAL_VECTOR_SUPPORT is calculated 1
(and is implemented by the platform HAL), the #ifdefs may just as well
be removed like in most other platfor HALs. Present eCos apps will not
run under old vrc437x stubs anyway...

Jonathan> And by the looks of it, platforms should indeed be
Jonathan> conditionalising on CLAIM_COMMS really (although the bloat
Jonathan> should be limited if selective linking works for your
Jonathan> target, which it does for mips).

No, they should not be conditionalising anything. The CDL decisions
are made and acted upon in the common HAL. The platform code is called
if needed and will be linker GC'd if not. At least that was the plan.

Jesper