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