Re: [ECOS] VxWorks type embedded "shell" for eCos

["Jeffrey R. Szczepanski" <jrs at inscitek dot com>]

"Nick Garnett" <nickg@ecoscentric.com> writes:

> 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.

This is plainly incorrect. You link with VxWorks "libtarget.a" type thing
just like eCos. You just don't get to see the source of the kernel. eCos is
clearly more fine grained level control of what you get and don't get. But,
Tornado basically lets you configure which objects of the VxWorks kernel and
supporting libraries link in and how they are configured.

eCos = source line by source line
VxWorks = object file by object file

In VxWorks they are configured as startup parameterization of the
initialization entry points for each module. In eCos, because you are
working at source level, you control with #defines instead via the
configuration tool.

The VxWorks load/unload feature is mainly just something to allow you to
debug from a static boot rom and dynamic load your code under test. eCos
uses Redboot. VxWorks allows you to load into the running executable
shell....however it also support the redboot style way by build two sets of
exectables....a VxWorks bootrom and seperate application that also has
VxWorks built into too....both statically linked just like eCos.

> 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.

We develop almost exclusively with static images - for the reason you say.
The VxWorks dynamic loading features is exactly that - a feature. You can
choose to include it or not - and once included, you can choose to use it or
not.

The dynamic loading does come in handy from time to time, when you have a
mis-behaving system any want to write up something quick to analyze what is
happening without having to reboot and lose the current state. Also useful
for loading in diagnostic or test exercise routines without altering the
static executable. The dynamic loader allows things to be added without
having things in the "real application" move around and potentially alter
the locations/behavior of things.

Talk to the Mars Rover guys who just fixed that FLASH file system problem on
Mars. They actually use the shell capabilities over a VERY long serial link
to do these types of things!

> 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.

I don't totally disagree, but much of the configuration is done at compile
time, by deciding what facility of the whole system you want to include.
Again, I just see eCos configurability as more finer grained.....allowing it
to scale from one extreme size to the other pretty easily. A nice advantage
of a source driven system. No question.

But in an absolute sense, once you start adding things like network stacks,
etc. in many systems, who really cares about the last 50K to 150K of code
savings when you are talking MB+ of total application sizes in many cases.

Regards,
Jeff

----- Original Message ----- 
From: "Nick Garnett" <nickg@ecoscentric.com>
To: <kevin_lemay@agilent.com>
Cc: <jrs@inscitek.com>; <ecos-discuss@sources.redhat.com>
Sent: Friday, February 06, 2004 6:19 AM
Subject: Re: [ECOS] 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