Bug 57934

Summary: CDL lacks slot assignment capability
Product: [Retired] eCos Reporter: Bart Veer <bartv>
Component: CDLAssignee: Bart Veer <bartv>
Status: CLOSED WONTFIX QA Contact: eCos bugs internal list <es-ecos-bugs-int>
Severity: medium Docs Contact:
Priority: medium    
Version: CVS   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-06-20 16:10:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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