From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jesper Skov <jskov@redhat.com>
To: Jonathan Larmour <jlarmour@redhat.com>
Cc: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>, eCos discussion <ecos-discuss@sources.redhat.com>, Gary Thomas <gthomas@redhat.com>, Jesper Skov <jskov@redhat.com>
Subject: Re: [ECOS] Tracing and Debug
Date: Sun, 23 Jul 2000 23:31:00 -0000
Message-id: <14715.58047.455679.283074@thinktwice.zoftcorp.dk>
References: <21DDE8E5343ED411840A00A0CC3340201047E9@EXCHANGE5_5> <3978D6C1.6D67C46A@redhat.co.uk>
X-SW-Source: 2000-07/msg00221.html

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

Jonathan> Jesper/Gary, do we have any CDL now that should prevent
Jonathan> this? I can't find any, but I didn't get the assertion above
Jonathan> when I tried it so is there some other mechanism? I suspect
Jonathan> the platform CDL for the debug serial port (now
Jonathan> CYGNUM_HAL_VIRTUAL_VECTOR_DEBUG_CHANNEL in the new world)
Jonathan> should require !CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT &&
Jonathan> !CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT

I guess we should put something in place to at least warn about this
conflict. The below contains the logic:

     cdl_option CYGNUM_HAL_VIRTUAL_VECTOR_DEBUG_CHANNEL {
        display          "Debug serial port"
        flavor data
        legal_values     0 to CYGNUM_HAL_VIRTUAL_VECTOR_COMM_CHANNELS-1
        default_value    0
        requires         !( ((CYGNUM_HAL_VIRTUAL_VECTOR_DEBUG_CHANNEL==0 &&\
                              CYGPKG_IO_SERIAL_ARM_PID_SERIAL0) || \
                             (CYGNUM_HAL_VIRTUAL_VECTOR_DEBUG_CHANNEL==1 &&\
                              CYGPKG_IO_SERIAL_ARM_PID_SERIAL1)) && \
                            (CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT || \
                             CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT))
        description      "
            The PID board has only one serial port. This option
            chooses which port will be used to connect to a host
            running GDB."
     }


But:

 o It's rather nasty to look at
 o The warning/error would appear at the wrong location - it really
   belongs in the common HAL with the CTRLC/BREAK options.

Maybe it could be done with interfaces.

Jesper