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

[Nick Garnett <nickg at ecoscentric dot com>]

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

> Ah yes! the first detractor to my query. I was hoping to get this kind of
> stuff discussion out in the open to have a good community discussion on the
> topic. It is no fun if everyone agrees. ;-)

Exactly. I'm partly playing devils advocate here. I want to be sure
that there is a genuine need for this facility, and that it is not
just being asked for simply because "that's what VxWorks does". I
don't want eCos to be transformed into a VxWorks clone any more than I
would like to see it made into a Linux clone. My other main concern is
that it does not have a negative impact on the complexity and
maintainability of eCos.

I'm certainly not against the kind of runtime controls being
suggested. The system monitor I produced as the HTTPD demonstrator
already includes some of them. However, eCos was not designed to be an
interactive OS, so we must be careful not to let the demands of the
shell cause us to elaborate the rest of eCos beyond what is sensible.

> Again, I think you are not familar. I have worked on 5 major projects in my
> career on embedded systems...all of them shipped to the field with the shell
> embedded in the product and available through some mechanism...either
> launchable or always available via telnet connection. It allows lots of
> things to be discovered if there are problems/issues without using GDB.

I would worry about the security of any system that had the shell
still installed. Particularly if it were open to remote access. But I
suppose that really depends on the application. For something that
goes into an already secure environment, or where it is not an issue
then leaving the shell in is no problem. But for something like a
mobile phone or in a nuclear power plant things are very different.

> 
> In fact, I would argue that GDB running is actually much more instrusive to
> the running target. A shell running on an interrupt driven serial port, when
> the shell thread runs low priority has almost no impact on a system in
> normal operation....comes close to allow observing a running system without
> modifying behavior significantly.
> 
> Relative to launching things....it is not about launching application
> things. It's about running commands that dump internal information. See the
> thread list and what is runnable/suspended. Dump a table of a database, or
> list the set of allocated objects of a certain type. See how much heap is
> available, etc.

I can see the usefulness of being able to do such things during the
test and debug cycle. I'm not so sure about deployment, when it is not
clear that anybody who knows anything about the shell will ever get
anywhere near the failed device. But I suspect that we are thinking
about very different usage scenarios.

> 
> > 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.
> 
> Tornado came way after the basic shell. I have something basic running
> already. It does much of the powerful things of the shell relative to
> examination and monitoring of a running system. My shell object file is 54K
> including debugging information! The actual .text segment size is a whopping
> 2664 bytes of ARM code compiled. Relative to the symbols, yes they can add
> up....but the point is that is is small relative to the total executable
> size.

Looking at the symbols in a typical network application, I reckon the
symbols in there would easily require a 50k table. Looking at the
command processor in RedBoot and assuming that the shell would need
similar functionality, adding the device drivers and infrastructure, I
reckon 20-30k there. So maybe 100k was somthing of an overstatement, I
still reckon 60-70k.

> Besides who cares about 100K of symbol table when you have a 3MB
> exectable. 100K is not what it used to be.

Sure. But we are now seeing single chip systems with 256k RAM and 512k
flash on-chip. eCos is ideal for these, but only if we can squeeze
into the available space. There, even 30k for the shell is
significant.

> Again, if you application is
> small, so is your symbol table....and there is no strict reason to include
> all symbols....many times you don't care about most of the kernel ones, only
> the application ones.

It depends on how deep you want to go into the system when
debugging. Unlike VxWorks there is no clear division between eCos and
the application, so it's not clear where the cutoff point between user
symbols and system symbols comes. Being able to call system routines
would be a useful feature. But it all depends on how the symbol table
gets constructed.

> 
> > 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.
> 
> My current shell is a completely stand-alone library. It is completely
> optional. No modifications to the eCos kernel at all. It a simple set of
> interactive services that work off where ever stdin/stdout is being
> directed.....using a simple tty driven serial port or a network connection
> via telnet.
> 
> You bring up all the GDB mangling stuff, etc. I would be willing to bet
> there is significantly less code in the current shell vs. that stuff for GDB
> support (not counting the symbols of course). I'm sure if you ran with my
> shell instead of the GDB stuff, the executable would be smaller.

Most of what is in the eCos executable to support GDB would also be
needed to support the shell. Most of it is in RedBoot.

My main concern with regard to GDB is issues like the IO redirection
that RedBoot does. Another issue is what happens if a shell, loaded
via GDB, sets a breakpoint. Who fields the exception? What happens if
GDB has also set breakpoints? What happens if the application is also
fielding exceptions? It can get complicated.

> I understand and share your concerns. The right approach is for this to be
> completely isolated set of facilities. I think little, if anything, needs to
> be done to the kernel to support what I have in mind. I think the only thing
> architectural I would see in the future for this shell is a HAL/Architecture
> level support for doing the architecture specific things like a stack dump,
> setting a breakpoint, etc. since those would be architecturally specific.
> Again, I think those in addition to the shell would be completely optional
> set of packages.

Stack backtrace can be hard, the code in GDB to do this is a twisty
maze of heuristics -- and even then it doesn't always get it
right. Breakpoints could easily use the existing GDB support code,
allowing for the issues above.

> 
> BTW, didn't that "C" in eCos standard for Configurable?

It does, but we do have to be careful. There are parts of eCos which
are already too full of ifdefs. We need to ensure that eCos remains
stable and maintainable. Leakage of dependencies and config options
from package to package is a problem that needs to be controlled. So
long as the shell is self contained, then there is no problem. Once it
starts demanding fundamental changes to the rest of the system then it
becomes an issue.

I'm not against the idea of a shell at all, in fact the more think
about it, the more I think it would be a good idea. But I do want to
make sure that it is being done for the right reasons and does provide
some useful features.

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