Bug 57934 - CDL lacks slot assignment capability
CDL lacks slot assignment capability
Status: CLOSED WONTFIX
Product: eCos
Classification: Retired
Component: CDL (Show other bugs)
CVS
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bart Veer
eCos bugs internal list
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-01-02 11:36 EST by Bart Veer
Modified: 2007-04-18 12:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-06-20 12:10:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bart Veer 2002-01-02 11:36:30 EST
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 11:48:29 EST
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 12:10:03 EDT
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.