[ECOS] CDL Interface Configury

[ECOS] CDL Interface Configury

[Jay Foster]

I'm having a problem using the cdl_interface CDL configury. I have a CDL
package where I have:

	requires	(CYGINT_XXX == 1)


	cdl_interface CYGINT_XXX {
		display	""
	}


I (currently) do not have any implementations for this interface enabled.  I
would expect to get a CDL configure error, but do not.  Instead, I get:

	U CYGINT_XXX, new inferred value 1

as output from ecosconfig.  Why is that?  How do I make ecosconfig fail if
the requirement is not met, rather than inferring a value for it?  The
result of the ecosconfig not failing is that the compile then fails later,
since there is no implementation code.

Jay

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

Re: [ECOS] CDL Interface Configury

[Andrew Lunn]

On Fri, Oct 12, 2007 at 10:40:18AM -0700, Jay Foster wrote:
> I'm having a problem using the cdl_interface CDL configury. I have a CDL
> package where I have:
> 
> 	requires	(CYGINT_XXX == 1)
> 
> 
> 	cdl_interface CYGINT_XXX {
> 		display	""
> 	}

The interface should be declared outside of the package that requires
it be implemented.

Taking a random example: CYGINT_DEVS_DISK_MMC_SPI_CONNECTORS in

devs/disk/generic/mmc/current/cdl/devs_disk_mmc.cdl

   Andrew

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

Re: [ECOS] CDL Interface Configury

[Gary Thomas]

Andrew Lunn wrote:
> On Fri, Oct 12, 2007 at 10:40:18AM -0700, Jay Foster wrote:
>> I'm having a problem using the cdl_interface CDL configury. I have a CDL
>> package where I have:
>>
>> 	requires	(CYGINT_XXX == 1)
>>
>>
>> 	cdl_interface CYGINT_XXX {
>> 		display	""
>> 	}
> 
> The interface should be declared outside of the package that requires
> it be implemented.
> 
> Taking a random example: CYGINT_DEVS_DISK_MMC_SPI_CONNECTORS in
> 
> devs/disk/generic/mmc/current/cdl/devs_disk_mmc.cdl

Or use 'active_if' instead.  This will just make the CDL item
in question not be able to be activated.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

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

Re: [ECOS] CDL Interface Configury

[Bart Veer]

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

    Jay> I'm having a problem using the cdl_interface CDL configury. I
    Jay> have a CDL package where I have:

    Jay> 	requires	(CYGINT_XXX == 1)

    Jay> 	cdl_interface CYGINT_XXX {
    Jay> 		display	""
    Jay> 	}


    Jay> I (currently) do not have any implementations for this
    Jay> interface enabled. I would expect to get a CDL configure
    Jay> error, but do not. Instead, I get:

    Jay> 	U CYGINT_XXX, new inferred value 1

    Jay> as output from ecosconfig. Why is that? How do I make
    Jay> ecosconfig fail if the requirement is not met, rather than
    Jay> inferring a value for it? The result of the ecosconfig not
    Jay> failing is that the compile then fails later, since there is
    Jay> no implementation code.

This should not be happening, and when I try it in my world I get
reported conflict from ecosconfig as expected. Within libcdl an
interface is not directly modifiable, it should be impossible for the
inference engine to change its value directly. Instead the only ways
in which the inference engine can affect an interface is by making it
active or inactive, or by changing the state/value of something that
implements the interface.

If you look at the generated ecos.ecc file, what does it say about
CYGINT_XXX? My ecos.ecc contains the following:

  cdl_interface CYGINT_XXX {
    # No options implement this inferface
    # This value cannot be modified here.
    # Flavor: data
    # Current_value: 0

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

>>>>> "Andrew" == Andrew Lunn <andrew@lunn.ch> writes:

    Andrew> The interface should be declared outside of the package
    Andrew> that requires it be implemented.

No, there is no such requirement within CDL. If the parent package has
an active_if on the interface then things can get confusing, but that
is a separate issue. Here we are talking about requires properties.

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

Re: [ECOS] CDL Interface Configury

[Bart Veer]

>>>>> "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

RE: [ECOS] CDL Interface Configury

[Jay Foster]

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

My (simplified) CDL file has:

	requires		1 == CYGINT_XXX

	cdl_component CYGPKG_A_OPTIONS {
		flavor			none
		no_define

		cdl_interface CYGINT_XXX {
		}

		cdl_option CYGOPT_OPTION_A {
			flavor			bool
			default_value	0
			implements		CYGINT_XXX
		}

		cdl_option CYGOPT_OPTION_B {
			flavor			bool
			default_value	0
			implements		CYGINT_XXX
		}

The .ecc file has:

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

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

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

Jay

-----Original Message-----
From: Bart Veer [mailto:bartv@ecoscentric.com]
Sent: Sunday, October 14, 2007 1:03 PM
To: Jay Foster
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] CDL Interface Configury


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

    Jay> I'm having a problem using the cdl_interface CDL configury. I
    Jay> have a CDL package where I have:

    Jay> 	requires	(CYGINT_XXX == 1)

    Jay> 	cdl_interface CYGINT_XXX {
    Jay> 		display	""
    Jay> 	}


    Jay> I (currently) do not have any implementations for this
    Jay> interface enabled. I would expect to get a CDL configure
    Jay> error, but do not. Instead, I get:

    Jay> 	U CYGINT_XXX, new inferred value 1

    Jay> as output from ecosconfig. Why is that? How do I make
    Jay> ecosconfig fail if the requirement is not met, rather than
    Jay> inferring a value for it? The result of the ecosconfig not
    Jay> failing is that the compile then fails later, since there is
    Jay> no implementation code.

This should not be happening, and when I try it in my world I get
reported conflict from ecosconfig as expected. Within libcdl an
interface is not directly modifiable, it should be impossible for the
inference engine to change its value directly. Instead the only ways
in which the inference engine can affect an interface is by making it
active or inactive, or by changing the state/value of something that
implements the interface.

If you look at the generated ecos.ecc file, what does it say about
CYGINT_XXX? My ecos.ecc contains the following:

  cdl_interface CYGINT_XXX {
    # No options implement this inferface
    # This value cannot be modified here.
    # Flavor: data
    # Current_value: 0

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

>>>>> "Andrew" == Andrew Lunn <andrew@lunn.ch> writes:

    Andrew> The interface should be declared outside of the package
    Andrew> that requires it be implemented.

No, there is no such requirement within CDL. If the parent package has
an active_if on the interface then things can get confusing, but that
is a separate issue. Here we are talking about requires properties.

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

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