Re: [ECOS] package definition with CDL

[Bart Veer <bartv at redhat dot com>]

>>>>> "Joerg" == =?iso-8859-1?B?SvZyZyBSYXBrYQ==?=  <iso-8859-1> writes:

    Joerg> Hello
    Joerg> I'm about to port eCos to M68k. My target uses the M68331
    Joerg> microcontroller.

    Joerg> I have defined a package "M68k" as architecture HAL and I
    Joerg> have defined a package "my_target" as platform HAL.

    Joerg> I try to find out what are the HAL packages between.

    Joerg> The M68331 microcontroller is one of the M683xx family. So
    Joerg> the M683xx is a variant of the M68k architecture. My first
    Joerg> idea was to define the package "M683xx" as architecture
    Joerg> variant HAL. Within this package the current used
    Joerg> microcontroller should be selectable (e.g. M68331,
    Joerg> M68332,...). Since my target board need the M68331 (e.g.
    Joerg> the M68332 is not compatible with the M68331), the M68331
    Joerg> should be active in the "M683xx" architecture variant HAL
    Joerg> package, if "my_target" platform HAL is used. How can I
    Joerg> implement this dependency in CDL?

    Joerg> Summary:
    Joerg> My target "my_target" is defined by the following packages:

    Joerg> - M68k architecture HAL
    Joerg> - M683xx architecture variant HAL (microcontroller M68331
    Joerg>   must be selected) 
    Joerg> - my_target platform HAL

    Joerg> Or any other idea how to define the packages for the M68k?

This combination of M68k architectural HAL, M683xx variant HAL, and
target-specific platform HAL sounds right.

In the variant HAL you will want one or more configuration options to
control the specific microcontroller. This could be a single option,
e.g.:

  cdl_option xxxHWR_HAL_M683XX_VARIANT {
      flavor data
      legal_values { M68331 M68332 }
  }

(The CDL naming conventions allow you to pick a suitable xxx prefix.
If you intend to contribute the port and assign copyright then feel
free to use CYG, but that is not required).

In the variant HAL code you can then use
"#ifdef xxxHWR_HAL_M683XX_VARIANT_M68331" for 68331-specific code,
and so on. In the platform HAL you can have a "requires" property of
the form:

  requires { xxxHWR_HAL_M683XX_VARIANT == "M68331" }

and everything should work pretty much as expected. If the default
value for the variant HAL configuration option is M68331 then
everything is fine. If the default value is something else then the
configuration tools will detect the conflict and the inference engine
should resolve it automatically (as long as there are no complicated
dependencies in this area). If the user explicitly changes the
variant to something else then the configuration tools will detect and
report the conflict - the user can still proceed, but there are no
guarantees that anything will work.

There is one small problem with this approach: what happens if a third
party wants to add support for another variant by adding another
package. There is no way for this new package to extend the
legal_values property for xxxM683XX_HAL_M68K_VARIANT. Theoretically
the CDL language could be extended to allow package A to override
properties of another package B, but then the maintainer of package B
would no longer have any idea about what is going to end up in that
package's configuration header file and anything could happen.

Instead each microprocessor variant is controlled by a separate
boolean configuration option, implementing a common interface, and
that interface has a constraint that there is only one implementation
(i.e. that only one microprocessor variant has been selected).

  cdl_interface xxxINT_HAL_M683XX_VARIANT {
      requires { 1 == xxxINT_HAL_M683XX_VARIANT }
      ...
  }

  cdl_option xxxHWR_HAL_M683XX_M68331 {
      implements xxxINT_HAL_M683XX_VARIANT
      ...
  }

  cdl_option xxxHWR_HAL_M683XX_M68332 {
      implements xxxINT_HAL_M683XX_VARIANT
      ...
  }

A third party packages could then define additional variant options
without having to change an existing package.

The platform-specific HAL can require a particular variant:

  requires xxxHWR_HAL_M683XX_M68331

and everything should get sorted out by the configuration tools as
before.

There should be some examples of this sort of thing in the existing
HAL sources - the PowerPC MPC8xx support might be a good starting
point.

Bart