This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Self defining CDL interfaces

>>>>> "Jifl" == Jonathan Larmour <> 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:
        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.
            calculated 4

        # This allows packages to provide sensible stack size options.

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 Veer                       eCos Configuration Architect     The eCos and RedBoot experts

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]