Bug 57934 - CDL lacks slot assignment capability
Summary: CDL lacks slot assignment capability
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: eCos
Classification: Retired
Component: CDL
Version: CVS
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bart Veer
QA Contact: eCos bugs internal list
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-01-02 16:36 UTC by Bart Veer
Modified: 2007-04-18 16:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-06-20 16:10:03 UTC
Embargoed:


Attachments (Terms of Use)

Description Bart Veer 2002-01-02 16:36:30 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901

Description of problem:
From an ecc-eng posting by Jesper, 20 July 2000:

What would be nice is if the stub (and RedBoot) could have:

cdl_option FOO {
 implements CYGNUM_HAL_VIRTUAL_VECTOR_AUX_CHANNELS

}

cdl_option BAR {
 implements CYGNUM_HAL_VIRTUAL_VECTOR_AUX_CHANNELS

}

and somehow be told which index they were assigned, for example by
creation of an automatic option:

 #define CYGNUM_HAL_VIRTUAL_VECTOR_AUX_CHANNELS_FOO 0
 #define CYGNUM_HAL_VIRTUAL_VECTOR_AUX_CHANNELS_BAR 1

Then the individual (serial) channels could also be assigned via CDL
instead of hardwired into the code. The PID code, presently looks like:

    // Set channel 0
    CYGACC_CALL_IF_SET_CONSOLE_COMM(0);
                                    ^ magic constant
    comm = CYGACC_CALL_IF_CONSOLE_PROCS();
    CYGACC_COMM_IF_CH_DATA_SET(*comm, &pid_ser_channels[0]);

    // Set channel 1
    CYGACC_CALL_IF_SET_CONSOLE_COMM(1);
                                    ^ magic constant
    comm = CYGACC_CALL_IF_CONSOLE_PROCS();
    CYGACC_COMM_IF_CH_DATA_SET(*comm, &pid_ser_channels[1]);

The magic constants could be replaced accordingly... Even though the
option names would be monster long. Maybe something like this would be
better:

 implements --assigned-value=CYGNUM_CHANNEL_PID_SERIAL_0
CYGNUM_HAL_VIRTUAL_VECTOR_AUX_CHANNELS

so we get

  #define CYGNUM_CHANNEL_PID_SERIAL_0 <whichever number it is assigned>



Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.try to use --assigned-value with an implements property in a CDL
  script
2.
3.
	

Actual Results:  An error message.

/home/bartv/ecc/ecc/devs/usb/nec_upd985xx/current/cdl/usbs_upd985xx.cdl,
package CYGPKG_DEVS_USB_UPD985XX, property implements: warning
    Invalid option `assigned-value'.


Additional info:

Comment 1 Bart Veer 2002-01-02 16:48:29 UTC
The requested functionality is reasonable and would also be useful in
other circumstances, e.g. assigning per-thread-data slots to different
packages. However the suggested implementation is not quite right.
A better approach would be to extend the CDL expression syntax with
list functionality. First we add a new function implementors() which
can be applied only to an interface and returns a list of all active
and enabled valuables that implement this interface. Then we provide
additional functions to manipulate lists, for example an lsearch()
function. Getting the desired slot number would then involve
something like:

  lsearch(implementors(CYGNUM_HAL_VIRTUAL_VECTOR_AUX_CHANNELS), FOO)

or perhaps a utility function

  get_implementor_index(CYGNUM_HAL_VIRTUAL_VECTOR_AUX_CHANNELS, FOO)

However making the required information available in a header file
would still be a problem. This should involve something like:

  define_proc {
      set index [cdl_eval
lsearch(implementors(CYGNUM_HAL_VIRTUAL_VECTOR_AUX_CHANNELS), FOO)]
      puts $cdl_header "#define FOO_INDEX $index"
  }

However script-level access to configuration data is not yet
implemented. An ugly workaround would be to invent new calculated
options which use the above expression to calculate their value, but
it should not be necessary to invent spurious configuration options
for this sort of thing.


Comment 2 Alex Schuilenburg 2003-06-20 16:10:03 UTC
This bug has moved to http://bugs.ecos.sourceware.org/show_bug.cgi?id=57934


Note You need to log in before you can comment on or make changes to this bug.