Re: [ECOS] 'enable' in 'ecos.db'

[Bart Veer <bartv at redhat dot com>]

>>>>> "Jura" == Jurica Baricevic <jura@INTESIS.hr> writes:

    Jura> Which is the best way for maintaining HAL sources for very
    Jura> similar platforms? By 'very similar' I meant that only a few
    Jura> lines of HAL code should be changed from one platform to
    Jura> another. The obvious solution is to have a HAL package for
    Jura> each platform, but it is very hard to keep and update i.e.
    Jura> five (or more) almost the same source trees. Is there some
    Jura> more 'elegant' solution in eCos? I would like to have only
    Jura> one source tree with a few #ifdef statements in sources and
    Jura> a simple mechanism for *automatic* choosing appropriate
    Jura> switches by selecting particular target. I noticed keyword
    Jura> 'enable' (in 'ecos.db' file) that could probably help me in
    Jura> my endeavors, but it is not documented.

There are a number of approaches that can be taken, depending on just
how extensive the differences between the boards are. Unfortunately
hardware tends to get messy, so no solution is going to be perfect.

Suppose that there is an original board X and a later board XX which
is compatible but contains some extra devices. The platform HAL for
board X can be re-used for board XX without changes. The ecos.db
target entry for XX specifies this platform HAL, plus additional
device driver packages.

If the platform HAL needs very minor tweaks to support the extra
devices e.g. to initialize them (although other approaches such as C++
priorities constructors might be more appropriate), this can be
accommodated. The platform HAL would #include <pkgconf/system.h>, and
it can then use #ifdef to find out which packages are loaded in the
current configuration. Specifically it can check for the presence of
the extra device driver packages and do the right thing. This approach
is not totally robust: the end user may decide to remove the unwanted
device drivers from the configuration, in which case the platform HAL
would now think it is running on a target X instead of XX. If the
extra devices are harmless on power up, i.e. they do not actually do
anything until some code explicitly activates them, then this approach
can be acceptable.

In practice hardware is generally messy so the above scheme will not
quite work, for one reason or another. For example the list of device
drivers is exactly the same, but memory needs to be initialized
differently, or there is an interrupt subsystem, or something along
those lines. At this point you will need a new platform HAL package,
but usually code duplication can be avoided. Instead the target entry
in the ecos.db file lists both the XX-specific platform HAL and the
more generic X platform HAL. The CDL scripts for XX can now manipulate
configuration options in X using "requires" properties, and the code
in the X hal can adapt to these options. The XX package can also
provide additional code, as required. If the actual application will
run on yet another board Y, almost but not quite the same as XX, then
the user can still select XX as the target hardware, adjust these
configuration options for Y, and ignore the unresolved requires
constraints reported for package XX. This avoids a separate platform
HAL package for Y, and may be especially useful if the final target
hardware is still evolving and the code has to cope with a number of
different prototypes.

An alternative and cleaner approach involves three packages: one for
board X, one for board XX, and a common package. The ecos.db target
entries for the two boards specify this common package as well as the
appropriate board-specific one. The board-specific packages can affect
the behaviour of the common package by CDL "requires" constraints, as
before. This organization, a common package plus more specific
packages, is the one I normally recommend. Note that such common
packages can be nested, e.g. you can have a package xxxPKG_AAA_COMMON
with instances xxxPKG_AAA_ALPHA and xxxPKG_AAA_BETA, and then lower
down you can have xxxPKG_AAA_GAMMA_COMMON, xxPKG_AAA_GAMMA_ALEPH, ...

There are various examples of such common packages in the existing
eCos sources, e.g. the common HAL plus the architectural HALs, each
architectural HAL plus its variants, and so on.


The "enable" and related commands in the ecos.db file are not yet
documented. This information is supposed to go in the final chapter of
the Component Writer's Guide, which I have not yet finished. Basically
there are three commands you can put in a target entry:

  enable    <option>
  disable   <option>
  set_value <option> <value>

The first two affect the boolean part of the specified configuration
option. The last one affects the data part. So if a particular target
needs a certain configuration option enabled then this can be handled
by an "enable" command in the ecos.db file.

However, these commands should not be used in normal circumstances.
Instead "requires" properties in the appropriate CDL script should be
preferred (which does assume that there is a package to hold that
CDL). The inference engine in the configuration tools can then be left
to do the right thing. The ecos.db functionality is there partly to
work around limitations in the inference engine while the latter was
still being developed. It can also be useful for debugging or as a
temporary work-around before the proper implementation is ready.

There is one very good reason why "requires" properties should be
preferred to the use of these ecos.db commands. The commands only take
effect at the point that the target hardware is selected. If the user
subsequently changes one of these options then there is no constraint
in the system anywhere to warn the user that the configuration is not
actually valid for the target hardware. Things could get very
confusing...


I am afraid this has turned into a rather lengthy answer to a
non-trivial question, but I hope it proves useful.

Bart