This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Conditional CDL
- From: amit dot goel at st dot com
- To: ecos-discuss at sources dot redhat dot com
- Date: Wed, 26 Mar 2003 09:11:15 +0530
- Subject: [ECOS] Re: Conditional CDL
If , I have mailed at a incorrect forum , then I apologise for the
same and request for the e-mail id where I should put my question to.
I was planning to consider eCos for one of our applications.
Is it possible to know the Context switching time and Interrupt
latency time of ecos for ARM7/ARM9 platform.
2) I believe that if I have to port the Linux protocols on eCos , then
I need to have EL/IX layer which will give eCos the required posix
interface.Where can I get the source code for EL/IX layer which will
make eCos compatible to Linux ?
Thanks and Best Regards
Amit
______________________________ Reply Separator _________________________________
Subject: Re: Conditional CDL
Author: bartv (bartv at ecoscentric dot com) at internet-shar
Date: 3/24/2003 10:16 PM
>>>>> "Gary" == Gary Thomas <gary at mlbassoc dot com> writes:
Gary> I want to add a new platform which is just a tiny bit
Gary> different from an existing one.
So you are trying to support both platforms with a single platform HAL
package?
Gary> The problem I'm facing is that (this is in the PowerPC HAL)
Gary> we use CDL interfaces to indicate some properties about
Gary> platforms to the various variant and architectural layers.
Gary> In this case, the two platforms expose different interfaces,
Gary> but that's really the only difference.
Gary> Concrete info:
Gary> platform A:
Gary> implements property_X
Gary> implements property_Y
Gary> platform B:
Gary> implements property_Z
Gary> implements property_Y
Gary> The only way I know to do this would be to have a phony
Gary> cdl_component which has mututally exclusive cdl_options
Gary> nested within. I don't see any way to make the "implements"
Gary> statement conditional (at the statement level, only at the
Gary> component/option level).
Gary> Similarly, there are the set of "define proc" statements
Gary> which pass information to RedBoot (like the platform name).
Gary> I'd like these to be conditional as well.
Gary> Any good ideas on how I can do this (cleanly)?
"implements" properties belong to a node in the hierarchy, so you will
need separate options for the two platforms. Something like:
cdl_option platform_A {
default_value 0
implements property_X
implements property_Y
requires !platform_B
define_proc {
...
}
}
cdl_option platform_B {
default_value 0
implements property_Z
implements property_Y
requires !platform_A
define_proc {
...
}
}
Then have two target entries in ecos.db with appropriate "enable"
lines. Probably one additional line in the platform HAL package:
cdl_package <whatever> {
requires platform_A | platform_B
}
just to make sure that the user does not disable both platforms. There
is no need for a dummy component, these two options could go directly
below the package.
I think that is the cleanest that can be achieved at the moment. I
have thought about an enhanced version of implements, of the form:
implements_if <expr> <interface>
but I am not sure this would be sufficiently useful generally, and
there would be some problems parsing the property.
For the 2.1 timeframe I would like to extend CDL with cdl_target nodes
which behave largely like options, i.e. they can have requires
properties and the like, but which are also recognised by the admin
tool and result in appropriate entries in a generated ecos.db.
Bart
--
Bart Veer eCos Configuration Architect
http://www.ecoscentric.com/ The eCos and RedBoot experts
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss