Re: [ECOS] CDL Interface Configury

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "Jay" == Jay Foster <jay@systech.com> writes:

    Jay> Thanks, Bart. That is more like what I expected, but am not
    Jay> seeing. Here is a bit more information, which seems to be
    Jay> making the difference:

    Jay> My (simplified) CDL file has:

    Jay> 	requires		1 == CYGINT_XXX

    Jay> 	cdl_component CYGPKG_A_OPTIONS {
    Jay> 		flavor			none
    Jay> 		no_define

    Jay> 		cdl_interface CYGINT_XXX {
    Jay> 		}

    Jay> 		cdl_option CYGOPT_OPTION_A {
    Jay> 			flavor			bool
    Jay> 			default_value	0
    Jay> 			implements		CYGINT_XXX
    Jay> 		}

    Jay> 		cdl_option CYGOPT_OPTION_B {
    Jay> 			flavor			bool
    Jay> 			default_value	0
    Jay> 			implements		CYGINT_XXX
    Jay> 		}

    Jay> The .ecc file has:

    Jay> cdl_interface CYGINT_XXX {
    Jay>     # Implemented by CYGOPT_OPTION_A, active, enabled
    Jay>     # Implemented by CYGOPT_OPTION_B, active, disabled
    Jay>     # This value cannot be modified here.
    Jay>     # Flavor: data
    Jay>     # Current_value: 1

    Jay>     # The following properties are affected by this value
    Jay>     # package CYGPKG_MYPACKAGE
    Jay>     #     Requires: 1 == CYGINT_XXX
    Jay> };

    Jay> What I want is to have several optional implementations of an
    Jay> option (currently two implementations), and have the CDL
    Jay> enforce that one and only one of the options is configured.
    Jay> Normally, I would have the default value for one of the
    Jay> implementations set to '1' (true), and the rest '0' (false),
    Jay> but I set them both to false to test that the CDL fails if no
    Jay> implementation is configured. However, ecosconfig seems to be
    Jay> automatically enabling one of the options (the first one) to
    Jay> satisfy the requirement. Not what I want or expect.

This is very different from your original report where you claimed the
inference engine was modifying the value of CYGINT_XXX directly. I'll
assume that was caused by a typo of some sort.

What you are seeing is the correct behaviour at present. The inference
engine's job is to produce a configuration without conflicts. It
starts with an unsatisfied constraints CYGINT_XXX==1. It can satisfy
the constraint by enabling one of the implementors of that interface.
This does not cause any new conflicts. Job done. The user is informed
of what has changed by output like the following:

  U CYGOPT_OPTION_A, new inferred value 1

so if that inferred value does not correspond to what the user really
wants then she/he has the opportunity to edit ecos.ecc and resolve the
conflict in a different way, e.g. by explicitly enabling
CYGOPT_OPTION_B. This causes a new conflict because there are now two
implementors of the interface, so the next run of the inference engine
will disable CYGOPT_OPTION_A again. Alternatively the user can choose
to explicitly disable that, if preferred.

The important thing is that the user is in full control and is given
the information needed to make various decisions, while the tools try
to be as helpful as possible.

It can be argued that in some situations the inference engine should
not make certain changes, instead leaving conflicts unresolved. This
would require CDL extensions, e.g. a no_infer property which prevents
the inference engine from changing certain options. The counter
argument is that for e.g. automated testing it is very useful for all
conflicts to get resolved automatically whenever possible.

Bart

-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss