Re: [ECOS] difference between active / enabled components?

[Bart Veer <bartv at ecoscentric dot com>]

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