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

[Nick Garnett <nickg at ecoscentric dot com>]

"Jeffrey R. Szczepanski" <jrs@inscitek.com> writes:

> For people interested in a target debugger/shell capabilities under eCos:
> 
> The reason for my note here is to gauge interest in the set of capabilities
> normally associated with the VxWorks target shell type functionality. I
> would envision this as a new package for eCos that would allow users to
> configure in a target debugger/shell that is driven from the executable's
> symbol table information. Some initial capabilities might include:
> 
>     - calling arbitrary (public) C functions from the command line, with
> arguments/symbols of choice
>     - lookup symbols in the symbol table
>     - spawn threads
>     - pause/resume threads
>     - dump memory, and edit memory locations
>     - list information about all runnning threads (dump the task table)
>     - Uses any configured stdin/stdout based device for I/O
>     - dump stacks, disassemble memory
>     - etc.
> 

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

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.

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

BUT, I don't want to pour cold water on any ideas here. If people want
to add a shell to eCos, and they would find it useful, then go
ahead. However, I would be very reluctant to see any significant
changes made to the rest of eCos in order to accommodate it.

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