This is the mail archive of the ecos-discuss@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: VxWorks type embedded "shell" for eCos


<kevin_lemay@agilent.com> writes:

> Jeff,
> 
> We are currently exploring eCos and use VxWorks internally. The lack
> of a vxWorks type shell is one the detractors in moving away from
> vxWorks for us.

I would be interested to know what features of the the VxWorks shell
you find useful, and what you use them for. While I can see that some
of these things work well in the context of VxWorks, it is not clear
how they would translate to eCos, which is designed from a different
perspective.

> The second is the lack of dynamically unloading and reloading
> objects.

The main reason VxWorks has the object load/unload mechanism is that
it is a closed source system. The only way that they can support
configurability of the target system is to dynamically load code. eCos
is open source and based around compile-time configuration So there is
no need to dynamically load extra pieces of the system at runtime.
VxWorks also has Tornado to help it manage all this stuff for it --
something we don't have.

In any case, when it comes to finally deploying the system, you still
have to manufacture a static system image. And then go through another
entire test cycle to ensure that the behaviour of this image matches
that of the dynamically created system you debugged. I'm not convinced
that this wins you anything.

Since VxWorks is closed source, all config variations have to be
handled at runtime, and once compiled, any piece of code can be loaded
into any configuration. eCos has a lot of compile-time configuration,
which can change the size and layout of data structures, vary API
calls and even rename things. The result is that all loadable code
would have to be recompiled anyway -- so why not just link it straight
in to the final executable.


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


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