This is the mail archive of the
ecos-devel@sources.redhat.com
mailing list for the eCos project.
Re: Self defining CDL interfaces
>>>>> "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