Re: Self defining CDL interfaces

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "Jifl" == Jonathan Larmour <jifl@eCosCentric.com> writes:

    Jifl> Gary Thomas wrote:
    >> There are many examples of CDL which have comments like this:
    >> 
    >> # FIXME: This really belongs in the NS DP83902A package
    >> cdl_interface CYGINT_DEVS_ETH_NS_DP83902A_REQUIRED {
    >> display   "NS DP83902A ethernet driver required"
    >> }
    >> 
    >> These appear in target/platform instance CDL files.
    >> 
    >> Does anyone remember why this interface is not defined in the
    >> common/platform-independent CDL file?

    Jifl> Because those platform-independent CDL files are generally
    Jifl> active_if that interface themselves. It's catch-22: the
    Jifl> parent is active_if a cdl_interface, but if the parent
    Jifl> contains that cdl_interface itself it can never be enabled
    Jifl> because it's inactive!

    Jifl> I'd like to know what Bart's idea of a real solution would
    Jifl> be though. The only thing I can imagine is having a
    Jifl> CYGPKG_DEVS_ETH_NS_DP83902A_REALLY within
    Jifl> CYGPKG_DEVS_ETH_NS_DP83902A where the latter (the parent)
    Jifl> contains the cdl_interface, but it's the latter that has the
    Jifl> active_if. But this is icky fluff that just makes the whole
    Jifl> lot more confusing.

    Jifl> My preference would be for cdl_interfaces always to be
    Jifl> active in the sense of being able to be implemented; so if
    Jifl> their parent is inactive, then that's similar to having a
    Jifl> no_define.

A real solution? Sounds like a challenge.

I think the key is to separate out the hardware definition from the
device driver configuration options. When you have a selected a
target that target will have certain chips, irrespective of whether or
not the device drivers for those chips are loaded/active/enabled. So
the cdl interfaces which specify the presence of those chips and
perhaps precise characteristics should go into a separate part of the
configuration hierarchy.

A first stab at a solution, not fully thought through, would be
something like this:

cdl_component CYGHWR_TARGET {
    display   "Target hardware details"
    parent    ""
    flavor    none

    cdl_component CYGHWR_TARGET_INTERFACES {
        display    "CDL interfaces implemented by this hardware"
        flavor    none
    }

    # And possibly, in future, something like:
    cdl_component CYGHWR_TARGET_CHARACTERISTICS {
        display    "Hardware characteristics"
        flavor     none

        # These would usually be in the architectural HAL. They might
        # depend on HAL configuration options such as whether to run
        # a chip in 32-bit or 64-bit mode.
        cdl_option CYGNUM_TARGET_TYPES_SIZEOF_INT {
            calculated 4
        }

        # This allows packages to provide sensible stack size options.
        cdl_option CYGNUM_TARGET_MINIMUM_STACKSIZE {
            ...
        }
        ...
    }
}

CYGHWR_TARGET, CYGHWR_TARGET_INTERFACES, and
CYGHWR_TARGET_CHARACTERISTICS would be defined by the common HAL. A
device driver would define an interface reparented below
CYGHWR_TARGET_INTERFACES, and a platform HAL would implement it.
The device driver can now have active_if dependencies on the interface
without problems.

For this to work cleanly I think we would need a guideline that
everything below CYGHWR_TARGET is calculated, not configurable. It
would be as if CYGHWR_TARGET was provided by a separate hardware
definition tool. If e.g. a HAL allows you to set the processor
endianness then there would be an option in the HAL to control this,
and a calculated option below CYGHWR_TARGET which reflects the current
setting. The HAL contains code so you can configure its behaviour. The
hardware is basically fixed.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts