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


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

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

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

What if one does not use GDB? Also, what if GDB is not available at a given
time....like in the field. Perhaps you are used to a different development
process than many. I am guessing that thousands of Wind River Customers
would disagree with you. I have heard from several people already that in
fact have been reluctant to switch to eCos because of the lack of a shell
facility....requesting my current implementation.

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

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.

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.

> 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. Besides who cares about 100K of symbol table when you have a 3MB
exectable. 100K is not what it used to be. 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.

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

....In fact, why are you guys polluting that nice clean kernel with all that
GDB crap, vector tables, etc, etc.!? - Ok, I am just jerking your chain.

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

I think the cold water is out of the glass already. Maybe if you said that
first. ;-)

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.

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

Best Regards,
Jeff


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