[ECOS] difference between active / enabled components?

[ECOS] difference between active / enabled components?

[Luqman Munawar]

hello,

I have a general question regarding the difference between an active and enabled option/components.

I have checked that there is a define for every option that is both active and enabled otherwise no define is created in the headers.

So what is the use of having both of them? Is it just for cosmetic reasons in configtools?


Thanks for any ideas.

Regards,

Luqman Munawar
-- 
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games! 
http://games.entertainment.web.de/de/entertainment/games/free

-- 
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] difference between active / enabled components?

[Gary Thomas]

Luqman Munawar wrote:
> hello,
> 
> I have a general question regarding the difference between an active and enabled option/components.
> 
> I have checked that there is a define for every option that is both active and enabled otherwise no define is created in the headers.
> 
> So what is the use of having both of them? Is it just for cosmetic reasons in configtools?

It's all about inferences;
   active - the option is "turned on", i.e. will affect the build
   enabled - the prerequisites for the item are active, so this item
             can be activated if desired

-- 
------------------------------------------------------------
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] difference between active / enabled components?

[Luqman Munawar]

hi, Thanks for your reply.

> It's all about inferences;
>    active - the option is "turned on", i.e. will affect the build

Well, my observation is that when an option is just active and not enabled then it does not affect the build. Since there is no define created in headers, no extra code can be activated.

>    enabled - the prerequisites for the item are active, so this item
>              can be activated if desired
> 

I concur. You can enable an option only when it is activated.

Regards,

Luqman Munawar


-- 
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games! 
http://games.entertainment.web.de/de/entertainment/games/free

-- 
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] difference between active / enabled components?

[Andrew Lunn]

On Fri, Feb 15, 2008 at 03:48:26PM +0100, Luqman Munawar wrote:
> hello,
> 
> I have a general question regarding the difference between an active and enabled option/components.
> 
> I have checked that there is a define for every option that is both active and enabled otherwise no define is created in the headers.
> 
> So what is the use of having both of them? 

Active and enabled are two different concepts in CDL.  See

http://ecos.sourceware.org/docs-latest/cdl-guide/language.properties.html

Basically, the active property indicates if the option can be
used. i.e. all the requirements of the option/package are fulfilled
and all its parents in the hierarchy are enabled. If the property is
active, you can then enable/disable it.

        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

[ECOS] enabling/disabling options

[Luqman Munawar]

Wel, my idea is to take away possibility of mangling with options in case this would end up in a corrupt build.

I know that the system warns in case of most conflicts but there are also cases when you can create a corrupt build without seeing any warning.


For my board, a derivative of freescale mx31 board, I am going to do following:

1) The option should never be enabled: Create an 

"active_if !CYGPKG_HAL_ARM_MX31_MYBOARD" 

for this option.

2) The option should always be enabled:
Create a "requires OPTION_NAME" in the cdl script for my board package as follows:

cdl_package CYGPKG_HAL_ARM_MX31_MYBOARD {
requires OPTION_NAME

}



Is this the way how it is intended in eCos?



Regards,

Luqman Munawar



-------- Original-Nachricht --------
> Datum: Fri, 15 Feb 2008 16:36:52 +0100
> Von: Andrew Lunn <andrew@lunn.ch>
> An: Luqman Munawar <haqim1@gmx.de>
> CC: ecos-discuss@ecos.sourceware.org
> Betreff: Re: [ECOS] difference between active / enabled components?

> On Fri, Feb 15, 2008 at 03:48:26PM +0100, Luqman Munawar wrote:
> > hello,
> > 
> > I have a general question regarding the difference between an active and
> enabled option/components.
> > 
> > I have checked that there is a define for every option that is both
> active and enabled otherwise no define is created in the headers.
> > 
> > So what is the use of having both of them? 
> 
> Active and enabled are two different concepts in CDL.  See
> 
> http://ecos.sourceware.org/docs-latest/cdl-guide/language.properties.html
> 
> Basically, the active property indicates if the option can be
> used. i.e. all the requirements of the option/package are fulfilled
> and all its parents in the hierarchy are enabled. If the property is
> active, you can then enable/disable it.
> 
>         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

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

-- 
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] enabling/disabling options

[Gary Thomas]

Luqman Munawar wrote:
> Wel, my idea is to take away possibility of mangling with options in case this would end up in a corrupt build.
> 
> I know that the system warns in case of most conflicts but there are also cases when you can create a corrupt build without seeing any warning.
> 
> 
> For my board, a derivative of freescale mx31 board, I am going to do following:
> 
> 1) The option should never be enabled: Create an 
> 
> "active_if !CYGPKG_HAL_ARM_MX31_MYBOARD" 
> 
> for this option.
> 
> 2) The option should always be enabled:
> Create a "requires OPTION_NAME" in the cdl script for my board package as follows:
> 
> cdl_package CYGPKG_HAL_ARM_MX31_MYBOARD {
> requires OPTION_NAME
> 
> }
> 
> 
> 
> Is this the way how it is intended in eCos?

Can you provide a bit more detail?  I'm not able to follow your
example since you've abstracted away too much detail.

There are certainly some examples in the CVS tree that are similar
to what you want.  Look at how the various models of the PowerPC
Adder platform are handled - hal/powerpc/adder.

> -------- Original-Nachricht --------
>> Datum: Fri, 15 Feb 2008 16:36:52 +0100
>> Von: Andrew Lunn <andrew@lunn.ch>
>> An: Luqman Munawar <haqim1@gmx.de>
>> CC: ecos-discuss@ecos.sourceware.org
>> Betreff: Re: [ECOS] difference between active / enabled components?
> 
>> On Fri, Feb 15, 2008 at 03:48:26PM +0100, Luqman Munawar wrote:
>>> hello,
>>>
>>> I have a general question regarding the difference between an active and
>> enabled option/components.
>>> I have checked that there is a define for every option that is both
>> active and enabled otherwise no define is created in the headers.
>>> So what is the use of having both of them? 
>> Active and enabled are two different concepts in CDL.  See
>>
>> http://ecos.sourceware.org/docs-latest/cdl-guide/language.properties.html
>>
>> Basically, the active property indicates if the option can be
>> used. i.e. all the requirements of the option/package are fulfilled
>> and all its parents in the hierarchy are enabled. If the property is
>> active, you can then enable/disable it.
>>
>>         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
> 


-- 
------------------------------------------------------------
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] enabling/disabling options

[Luqman Munawar]

hi Gary,


> > 1) The option should never be enabled: Create an 
> > 
> > "active_if !CYGPKG_HAL_ARM_MX31_MYBOARD" 
> > 
> > for this option.
> > 

Ok, there is an option in eCos system CYGHWR_DEVS_FLASH_AMD_AM29F which is in package CYGPKG_DEVS_FLASH_AMD_AM29XXXXX. This option is visible in configtool and can be enabled or disabled. 

I have another flash chip (CYGHWR_DEVS_FLASH_S29WS256N) in my board and don't like the idea that someone chooses the wrong flash chip instead of or additionally to the correct one and thus creates a non-working build. 

For this purpose I would deactivate all chips which are not on my board. The idea is show only option in the configtool which would not corrupt the final build.

I would write the following line in every chip that is not on my board:

"active_if !CYGPKG_HAL_ARM_MX31_MYBOARD"

Sounds like a very tideaus job. But I see no other alternative.


> > 2) The option should always be enabled:
> > Create a "requires OPTION_NAME" in the cdl script for my board package
> as follows:
> > 
> > cdl_package CYGPKG_HAL_ARM_MX31_MYBOARD {
> > requires OPTION_NAME
> > 
> > }
> > 



Now I don't like the user to able to disable the correct flash chip and write following in the package description of my board

requires  CYGHWR_DEVS_FLASH_S29WS256N


> There are certainly some examples in the CVS tree that are similar
> to what you want.  Look at how the various models of the PowerPC
> Adder platform are handled - hal/powerpc/adder.
> 

For me this looks like way to do what I have stated above. If anyone has a better idea how it is inteded in eCos, I would love to hear.

-- 
Regards,

Luqman Munawar

Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

-- 
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] difference between active / enabled components?

[Bart Veer]

>>>>> "Luqman" == Luqman Munawar <haqim1@gmx.de> writes:

    Luqman> hello,
    Luqman> I have a general question regarding the difference between
    Luqman> an active and enabled option/components.

    Luqman> I have checked that there is a define for every option
    Luqman> that is both active and enabled otherwise no define is
    Luqman> created in the headers.

    Luqman> So what is the use of having both of them? Is it just for
    Luqman> cosmetic reasons in configtools?

    Luqman> Thanks for any ideas.

Enabled vs. disabled is a user setting, whereas active vs. inactive is
a characteristic of the overall configuration. When an option is
active, the user can enable or disable it and that change will affect
the behaviour of the system. When an option is inactive, enabling or
disabling it will have absolutely no effect on the system's behaviour.

For example, consider the kernel's component CYGPKG_KERNEL_INSTRUMENT
and its sub-options like CYGDBG_KERNEL_INSTRUMENT_BUFFER_WRAP. The
component is always active when the kernel is loaded so users can
enable or disable it. If the component is disabled then the
sub-options are inactive: there is no point in enabling or disabling
CYGDBG_KERNEL_INSTRUMENT_BUFFER_WRAP, that will have absolutely no
effect on the system's behaviour. Making this clear in the user
interface avoids confusion when a user tries manipulating an inactive
configuration option and the system behaviour is unchanged.

Active vs. inactive dependencies cannot always be expressed using a
simple component/option hierarchy, hence the CDL active_if property.
The most obvious use is when some code depends on some hardware
functionality that may or may not be available. For example a serial
driver may only provide a device instance for a given uart if that
uart has a suitable connector on the target hardware. The
configuration system cannot magically change your hardware, so if an
option has a hardware dependency then an active_if property is
generally appropriate.

Sometimes active_if is useful for non-hardware dependencies. Consider
the gprof profiling package. That has an option CYGPKG_PROFILE_TFTP
allowing the collected profiling data to be transferred from target to
host via tftp. The option has a property "active_if CYGPKG_NET": tftp
transfers are only going to be possible when networking is available.

The more difficult question is when to use active_if vs. requires.
Instead of an "active_if CYGPKG_NET", CYGPKG_PROFILE_TFTP could
"require CYGPKG_NET". With an active_if, if you add the profiling
package to a configuration which does not have a networking stack then
everything is happy: the tftp option is simply inactive. With just a
requires, if you add the profiling package to a configuration without
a networking stack then you get a conflict that needs to be resolved.
Both approaches will end up with valid configurations, it is up to the
component developer to decide which is more appropriate.

Now, adding networking to a configuration is a pretty big step. People
are very unlikely to want to add networking just so that they can
transfer some profiling data via tftp. Hence an active_if is a more
appropriate property to use here than requires. It avoids any
conflicts that need to be resolved while still doing the right thing
for the vast majority of users of the profiling package. When the
dependency is on something much smaller than a TCP/IP stack then a
requires property is likely to be more appropriate than active_if.

There is a third approach: use both "requires CYGPKG_NET" and
"default_value CYGPKG_NET". This still gives a conflict-free
configuration irrespective of whether or not CYGPKG_NET is present.
If CYGPKG_NET is absent then CYGPKG_PROFILE_TFTP will now be active
but disabled, and if the user tries to enable it there will be a
conflict that needs to be resolved. The component developer gets to
decide whether or not this gives a more satisfactory user experience
than having the option inactive.

To conclude, there are rarely absolute answers, just shades of grey.
CDL provides mechanisms, it does not define rigid policies.

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] enabling/disabling options

[Bart Veer]

>>>>> "Luqman" == Luqman Munawar <haqim1@gmx.de> writes:

    <snip>
    Luqman> I have another flash chip (CYGHWR_DEVS_FLASH_S29WS256N) in
    Luqman> my board and don't like the idea that someone chooses the
    Luqman> wrong flash chip instead of or additionally to the correct
    Luqman> one and thus creates a non-working build.
    <snip>
    
    Luqman> If anyone has a better idea how it is inteded in eCos, I
    Luqman> would love to hear.

You may want to look at the V2 flash branch. The V2 AMD flash driver
supports CFI, so if you need to support boards which may come with
several different types of flash then CFI will give you run-time
detection of the actual hardware instead of static configuration of a
single type of flash.

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] difference between active / enabled components?

[Luqman Munawar]

hi Bart,

> 
> To conclude, there are rarely absolute answers, just shades of grey.
> CDL provides mechanisms, it does not define rigid policies.
> 
> Bart

thanks for your detailed elaborations. That helps understand the cdl concepts much better and see how you at ecocentric think about these things.

Regards,

Luqman Munawar
-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

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