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

[Kelvin Lawson]

> But you can do nearly all of this from GDB already. And those things
> that you cannot do are of very little utility anyway.

Is there a way to create a new thread running a specified function from 
GDB ? I find this very useful and don't think GDB supports it. It's very 
convenient for running quick tests - you can run a test function with 
different arguments without going through a rebuild and redownload cycle.

> In general eCos is an embedded operating system, not an interactive
> one. When you finally deploy whatever system you are building, it
> won't have a shell. I, for one, prefer to debug the program that I am
> actually going to execute. Having called arbitrary functions and
> spawned various threads, the resulting system would be totally unlike
> anything that gets deployed. I really don't see how you gain anything
> useful from that.

It's just my personal preference. I found the VxWorks shell made me more 
productive and enabled me to quickly run a bunch of tests on a target. 
Obviously these are not real-world tests and you wouldn't put something 
out the door having just run it from a shell internally. But it has a 
time and a place, and during development I found it made my life easier.

> The shell plus symbol tables is likely to occupy 100k+ of target-side
> memory. GDB uses minimal user side memory. We would also need some
> sort of host side processing to extract the symbol table from a built
> executable and then turn it into something that can be downloaded with
> the executable, presumably by relinking it. VxWorks has Tornado, a
> vast host-side infrastructure, to make all this invisible, we would
> have to create that from scratch.

I'm not sure what would be needed on the host-side. When I did a similar 
  shell for Nucleus, I just downloaded a COFF file to the target 
containing the symbol information, and extracted the symbols at runtime 
from the image in RAM. It takes a fair amount of memory so it's not 
suitable for everyone.

> I am also concerned that even the simplest of shells would be a thin
> end of the wedge for shoehorning lots of other interactive features
> into eCos, which would further bloat the code. Things are already
> complicated enough managing the interaction between RedBoot, eCos and
> GDB, adding a shell into the mix would make things even harder to
> maintain.

I agree that it shouldn't impose dependencies etc in the rest of the 
system but I don't think it needs to. Depending on the feature-set I 
think it could be well self-contained.

Cheers,
Kelvin.



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