This is the mail archive of the ecos-devel@sources.redhat.com 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


On Tue, 2003-09-30 at 04:22, Bart Veer wrote:
> >>>>> "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.
> 

So, could you recommend how we might restructure things for a real 
target?  I'm afraid that generalities are a bit confusing to me at
this point.

Take the FRV400 for example.  It has an onboard DP83902 network 
controller.  This is one of the drivers that has these funny
inter-dependencies.

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


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